* Re: [PATCHv3 3/4] submodule: add flags to ok_to_remove_submodule
From: Junio C Hamano @ 2016-12-14 23:48 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, David.Turner, bmwill, sandals
In-Reply-To: <20161214224101.6211-4-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> diff --git a/submodule.c b/submodule.c
> index 9f0b544ebe..2d13744b06 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1019,7 +1019,7 @@ int submodule_uses_gitfile(const char *path)
> return 1;
> }
>
> -int ok_to_remove_submodule(const char *path)
> +int ok_to_remove_submodule(const char *path, unsigned flags)
> {
> ssize_t len;
> struct child_process cp = CHILD_PROCESS_INIT;
> @@ -1032,15 +1032,27 @@ int ok_to_remove_submodule(const char *path)
> if (!submodule_uses_gitfile(path))
> return 0;
>
> - argv_array_pushl(&cp.args, "status", "--porcelain", "-u",
> + argv_array_pushl(&cp.args, "status", "--porcelain",
> "--ignore-submodules=none", NULL);
> +
> + if (flags & SUBMODULE_REMOVAL_IGNORE_UNTRACKED)
> + argv_array_push(&cp.args, "-uno");
> + else
> + argv_array_push(&cp.args, "-uall");
> +
> + if (!(flags & SUBMODULE_REMOVAL_IGNORE_IGNORED_UNTRACKED))
> + argv_array_push(&cp.args, "--ignored");
> +
These "internal values to assemble command line" operations we
cannot avoid. But things like this ...
> if (start_command(&cp))
> - die(_("could not run 'git status --porcelain -u --ignore-submodules=none' in submodule %s"), path);
> + die(_("could not run 'git status --porcelain --ignore-submodules=none %s %s' in submodule '%s'"),
> + (flags & SUBMODULE_REMOVAL_IGNORE_UNTRACKED) ? "-uno" : "-uall",
> + (!(flags & SUBMODULE_REMOVAL_IGNORE_IGNORED_UNTRACKED)) ? "--ignored" : "",
> + path);
and this ...
> if (finish_command(&cp))
> - die(_("'git status --porcelain -u --ignore-submodules=none' failed in submodule %s"), path);
> + die(_("'git status --porcelain --ignore-submodules=none %s %s' failed in submodule '%s'"),
> + (flags & SUBMODULE_REMOVAL_IGNORE_UNTRACKED) ? "-uno" : "-uall",
> + (!(flags & SUBMODULE_REMOVAL_IGNORE_IGNORED_UNTRACKED)) ? "--ignored" : "",
> + path);
makes me wonder if we want a helper that builds the string out of an
already assembled cp.args[] array, so that we won't have to do the
same thing twice/thrice and more importantly we won't have to worry
about these three going out of sync.
^ permalink raw reply
* Re: [PATCHv3 4/4] rm: add absorb a submodules git dir before deletion
From: Junio C Hamano @ 2016-12-14 23:55 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, David.Turner, bmwill, sandals
In-Reply-To: <20161214224101.6211-5-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> if (list.entry[i].is_submodule) {
> if (is_empty_dir(path)) {
> + if (rmdir(path))
> + die_errno("git rm: '%s'", path);
> + } else if (file_exists(path))
> + /* non empty directory: */
Lose colon?
> + remove_directory_or_die(path);
... otherwise? I.e.
else
???
If we are running "git rm -f <path>", then the path could be a
submodule in the index and on the filesystem, it could be (1)
already missing, as the user removed an empty submodule directory
she is not interested in, (2) a non-directory, e.g. a file or a
symbolic link, perhaps because she was trying to reorganize the
superproject working tree but decided against it, or (3) something
else?
(1) is perfectly OK; we end up with a result without the path, which
is what "git rm -f" wanted to do anyway. I am not sure what should
happen in (2), and what other corner cases there are for (3), though.
And use of file_exists(path) in the above patch may trigger a
strange error message in case (2), as remove_directory_or_die()
would say "path is not a directory", to which the user will say "Yes
I know, I wanted you to remove it with 'git rm -f'".
^ permalink raw reply
* Re: [PATCH v10 2/6] http: always warn if libcurl version is too old
From: Jeff King @ 2016-12-15 0:21 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, gitster, sbeller, bburky, jrnieder
In-Reply-To: <1481755195-174539-3-git-send-email-bmwill@google.com>
On Wed, Dec 14, 2016 at 02:39:51PM -0800, Brandon Williams wrote:
> Always warn if libcurl version is too old because:
>
> 1. Even without a protocol whitelist, newer versions of curl have all
> non-http protocols disabled by default.
Technically, non-http and non-ftp. Maybe just "non-standard" would be
more accurate.
Not worth a re-roll, but if Junio hasn't applied yet, maybe worth fixing
up while applying.
-Peff
^ permalink raw reply
* Re: [PATCH v10 0/6] transport protocol policy configuration
From: Jeff King @ 2016-12-15 0:22 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, gitster, sbeller, bburky, jrnieder
In-Reply-To: <1481755195-174539-1-git-send-email-bmwill@google.com>
On Wed, Dec 14, 2016 at 02:39:49PM -0800, Brandon Williams wrote:
> v10 of this series fixes the following:
> * A few updates to the commit messages in order to better convey the reasoning
> behind the a few of the patches.
> * Additional test to verify that curl redirects respect configured protocol
> policies.
> * Patch added by Jeff King to make http alternates respect configured
> protocol policies.
Thanks, this one looks fine to me.
-Peff
^ permalink raw reply
* git bug - merging JS / Node.js code with "git merge --squash"
From: Alexander Mills @ 2016-12-15 7:12 UTC (permalink / raw)
To: git
@git-community
I am on Git git version 2.7.4
This problem is happening on Ubuntu 16.04, but the same problem was
also happening when I was running on MacOS.
I am consistently seeing merge bugs, when merging between branches of
a mostly Node.js project.
I am seeing fairly bad merges that mangle the code in ways that seem
to clearly show some sort of Git bug. Some of these merges were for
files where there was likely not even a diff between the files.
TBH I am no Git expert, but maybe I will learn something from this
investigation.
The latest example of a mangled file is here:
https://github.com/ORESoftware/suman/blob/staging/suman.conf.js
You can see some repeat code, and also there is a dangling brace which
means that the file won't even "compile" with Node.js, using "$ node
-c". Notice that this file was *not* a file where I recently had to
manually merge code or manually fix a conflict, so I am hoping this is
not obvious operator error.
Here is the script I am using to merge between branches:
https://github.com/ORESoftware/suman/blob/dev/publish-suman.sh
basically it is doing the merge with this line:
git merge --squash -Xtheirs dev -m "squashing" &&
This is obviously very concerning because I can get very strange bugs
that I wouldn't expect, because I just assume that merges go well if
they succeed and it's hard to check for failure after that; even in a
compile statically typed language it could still prove difficult.
I am doing a check to make sure all my files compile with "node -c"
after the merge, but even then Git could create mangled code that
would still pass a "node -c" check.
Please let me know if this is a known bug and if there is a good
strategy to avoid it.
thanks!
--
Alexander D. Mills
(650)269-9502
alexander.d.mills@gmail.com
www.linkedin.com/pub/alexander-mills/b/7a5/418/
^ permalink raw reply
* Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'
From: Chris Packham @ 2016-12-15 7:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT, Markus Hitter, Jeff King, Jacob Keller
In-Reply-To: <xmqqk2b2xu81.fsf@gitster.mtv.corp.google.com>
On Thu, Dec 15, 2016 at 7:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The last one 3/3 is a nice touch that makes sure that we do not
> forget what we discovered during the discussion. Very much
> appreciated.
>
> Will queue. Thanks.
Did you want me to send a v4 to mark the strings for translation or
will you apply a fixup your end?
^ permalink raw reply
* Re: [PATCH v2] fix pushing to //server/share/dir on Windows
From: Torsten Bögershausen @ 2016-12-15 7:30 UTC (permalink / raw)
To: Johannes Sixt, Jeff King; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <787a421b-8b7a-14c5-768f-06c3dc183cf4@kdbg.org>
On 14/12/16 20:37, Johannes Sixt wrote:
> normalize_path_copy() is not prepared to keep the double-slash of a
> //server/share/dir kind of path, but treats it like a regular POSIX
> style path and transforms it to /server/share/dir.
>
> The bug manifests when 'git push //server/share/dir master' is run,
> because tmp_objdir_add_as_alternate() uses the path in normalized
> form when it registers the quarantine object database via
> link_alt_odb_entries(). Needless to say that the directory cannot be
> accessed using the wrongly normalized path.
>
> Fix it by skipping all of the root part, not just a potential drive
> prefix. offset_1st_component takes care of this, see the
> implementation in compat/mingw.c::mingw_offset_1st_component().
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Am 14.12.2016 um 18:30 schrieb Jeff King:
>> Would it be reasonable to
>> write:
>>
>> /* Copy initial part of absolute path, converting separators on Windows */
>> const char *end = src + offset_1st_component(src);
>> while (src < end) {
>> char c = *src++;
>> if (c == '\\')
>> c = '/';
>> *dst++ = c;
>> }
> Makes a lot of sense! I haven't had an opportunity, though, to test
> on Windows.
I'm not sure, if a conversion should be done here, in this part of code.
To my knowledge,
C:\dir1\file
is the same
as
C:/dir1/file
and that is handled by windows.
The \\server\share\dir1\file is native to windows,
and I can't see good reasons to change '\' into '/' somewhere in Git,
when UNC is used.
Cygwin does a translation from
//server/share/dir1/file
into
\\server\share\dir1\file
In other words:
The patch looks good as is, and once I get a Windows machine,
may be able to do some testing and come up with test cases
<https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx>
[]
^ permalink raw reply
* Cherry-pick applied X times
From: Delanoe, Yann @ 2016-12-15 8:12 UTC (permalink / raw)
To: git@vger.kernel.org
Hi Git community,
I'm new to GIT and responsible of a project to migrate our SVN repo to GIT.
I've made the migration with the git-svn tools ... it was long, but everything seems fine ; source code is correct and all its history is there.
It happen with our delivery workflow that we will have to use cherry-picks to prepare our patches, so I made some test on it.
During those tests I saw a strange behaviour: I tried to cherry-pick onto a release branch a commit from the master that had been previously already merged onto this branch with SVN. GIT did not detect it and added the code a second time in the source file modified. I supposed this was du the fact the first merge had been made with SVN. I tried to cherry pick the same commit again ... and GIT add one more time the code of the commit. It appears I could cherry-pick this commit X times with GIT, and each time he added the code again.
I looked in SVN, the merge property of the first commit from master to the release branch is ok.
Our SVN repo has more than 22K revisions
I found out that some other commits had the same behaviour.
Is there a direction onto which I should investigate to determine where the problem comes from ?
Here is an example of the multiple cherry pick.
Branches:
> git branch
master
* release/15.0.0
release/15.3.0
Check commit already exist on release (cb8c480) and get master hash (bee110c):
> git log --oneline |grep GTX-20264
cb8c480 GTX-20264 : Missing end of string in field hostReference for custom network ack
> git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
> git log --oneline |grep GTX-20264
bee110c GTX-20264 : Missing end of string in field hostReference for custom network ack
> git checkout release/15.0.0
Switched to branch 'release/15.0.0'
Your branch is up-to-date with 'origin/release/15.0.0'.
And now I cherry-pick the master commit onto the release/15.0.0 a multiple of times:
> git cherry-pick bee110c
[release/15.0.0 e8bfc33] GTX-20264 : Missing end of string in field hostReference for custom network ack
Author: Yann Delanoe <ydelanoe@bottomline.com>
1 file changed, 3 insertions(+)
> git cherry-pick bee110c
[release/15.0.0 2b98c8d] GTX-20264 : Missing end of string in field hostReference for custom network ack
Author: Yann Delanoe <ydelanoe@bottomline.com>
1 file changed, 3 insertions(+)
> git cherry-pick bee110c
[release/15.0.0 820cd8a] GTX-20264 : Missing end of string in field hostReference for custom network ack
Author: Yann Delanoe <ydelanoe@bottomline.com>
1 file changed, 3 insertions(+)
Best regards
Yann DELANOE - Product engineer - Bottomline technologies
^ permalink raw reply
* Re: [PATCH v2 3/6] update_unicode.sh: pin the uniset repo to a known good commit
From: Dennis Kaarsemaker @ 2016-12-15 9:47 UTC (permalink / raw)
To: Beat Bolli, git
In-Reply-To: <1481671904-1143-4-git-send-email-dev+git@drbeat.li>
On Wed, 2016-12-14 at 00:31 +0100, Beat Bolli wrote:
> + ( cd uniset && git checkout 4b186196dd )
Micronit, but this is perhaps better written as
git -C uniset checkout 4b186196dd
to avoid the subshell and cd.
D.
^ permalink raw reply
* Re: [RFC/PATCH v3 00/16] Add initial experimental external ODB support
From: Christian Couder @ 2016-12-15 9:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Nguyen Thai Ngoc Duy, Mike Hommey, Lars Schneider,
Eric Wong, Christian Couder
In-Reply-To: <xmqqshpr1tox.fsf@gitster.mtv.corp.google.com>
On Tue, Dec 13, 2016 at 9:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> In general I think that having a lot of refs is really a big problem
>> right now in Git as many big organizations using Git are facing this
>> problem in one form or another.
>> So I think that support for a big number of refs is a separate and
>> important problem that should and hopefully will be solved.
>
> But you do not have to make it worse.
>
> Is "refs" a good match for the problem you are solving? Or is it
> merely an expedient thing to use? I think it is the latter, judging
> by your mentioning RefTree. Whatever mechanism we choose, that will
> be carved into stone in users' repositories and you'd end up having
> to support it, and devise the migration path out of it if the initial
> selection is too problematic.
>
> That is why people (not just me) pointed out upfront that using refs
> for this purose would not scale.
What I should perhaps have clarified in my previous answer, and also
in the documentation of the patch series, is that in what I have done
and what I propose, the external odb helper is responsible for using
and creating the refs in refs/odbs/<odbname>/.
So this helper is free to just create one ref, as it is also free to
create many refs. Git is just transmitting the refs that have been
created by this helper.
Right now people are already free to use whatever external script or
software to create whatever refs/stuff/* they want, pointing to
whatever objects they want, and have Git transmit that. And indeed I
know that it is already a problem out there, as then people often get
into trouble related to having many refs. But it is a different
problem that is not going to be solved anyway in this patch series.
So if some people want to use a specific external odb, it's their
responsibility to use an helper that will not create too many refs.
If they know that they just need their external odb to handle around
10 big files, why wouldn't they use a simple helper that creates one
odb ref per big file/blob?
On the contrary if they know that they will need to handle thousands
of big files, then, yeah, they should find or implement a helper that
will, as I suggested in my previous email, just create one ref
in refs/odbs/<odbname>/ that points to a blob that contains a list
(maybe a json list with information attached to each item) of the
blobs stored in the external odb.
For testing purposes in what I have done in the patch series, I use
only simple helpers that create one odb ref per big file/blob. So yes,
it gives a bad example, because, if people just copy this design while
they need the e-odb to handle a big number of files, then they will be
in trouble. But this does not by itself carve anything into stone.
One thing that could help is perhaps to put big warnings into the
simple helpers saying "Be careful!!! This will not scale if you want
to handle more than a small number of large files!!! You'd better use
an helper that does <this and that> if you want to handle many large
files!!! You have been warned!!!".
So I am reluctant at this point to write a complex helper just for the
purpose of showing a good example to people who want to use e-odb to
store a big number of files, as these people anyway would probably
need something like Lars' "filter process protocol" too.
^ permalink raw reply
* Re: [PATCH v2] fix pushing to //server/share/dir on Windows
From: Jeff King @ 2016-12-15 11:01 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Johannes Sixt, Johannes Schindelin, Git Mailing List
In-Reply-To: <c8501e28-db8a-5b6e-717c-5bda1e63c2e7@web.de>
On Thu, Dec 15, 2016 at 08:30:52AM +0100, Torsten Bögershausen wrote:
> > > Would it be reasonable to
> > > write:
> > >
> > > /* Copy initial part of absolute path, converting separators on Windows */
> > > const char *end = src + offset_1st_component(src);
> > > while (src < end) {
> > > char c = *src++;
> > > if (c == '\\')
> > > c = '/';
> > > *dst++ = c;
> > > }
> > Makes a lot of sense! I haven't had an opportunity, though, to test
> > on Windows.
> I'm not sure, if a conversion should be done here, in this part of code.
> To my knowledge,
>
> C:\dir1\file
> is the same
> as
> C:/dir1/file
> and that is handled by windows.
I don't have an opinion either way on what Windows would want, but note
that the function already _does_ convert separators to slashes. With
Johannes's original patch, you'd end up with a mix, like:
\\server\share/dir1/file
So this conversion is really just retaining the original behavior, and
making it consistent throughout the path.
Which isn't to say that the function as it currently exists isn't a
little bit buggy. :)
One of the points of normalizing, though, is that Git can then do
textual comparisons between the output. So I think there's value in
having a canonical internal representation, even if the OS could handle
more exotic ones.
-Peff
^ permalink raw reply
* [PATCH 1/6] Enable ability to visualise the results of git cherry C1 C2
From: Pierre Dumuid @ 2016-12-15 11:28 UTC (permalink / raw)
To: paulus, git; +Cc: Pierre Dumuid
It's a bit clunky but it works!!
Usage:
- mark commit one (e.g. v45)
- Select commit two.
- Switch the gdttype to the option, "git-cherry between marked commit and:"
Signed-off-by: Pierre Dumuid <pmdumuid@gmail.com>
---
gitk | 110 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 107 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index a14d7a1..50d1ef4 100755
--- a/gitk
+++ b/gitk
@@ -2319,7 +2319,9 @@ proc makewindow {} {
[mc "containing:"] \
[mc "touching paths:"] \
[mc "adding/removing string:"] \
- [mc "changing lines matching:"]]
+ [mc "changing lines matching:"] \
+ [mc "git-cherry between marked commit and:"] \
+ ]
trace add variable gdttype write gdttype_change
pack .tf.lbar.gdttype -side left -fill y
@@ -4707,6 +4709,18 @@ proc gdttype_change {name ix op} {
global gdttype highlight_files findstring findpattern
stopfinding
+
+ if {$gdttype eq [mc "git-cherry between marked commit and:"]} {
+ if {$highlight_files ne {}} {
+ set highlight_files {}
+ hfiles_change
+ }
+ findcom_change
+ update_gitcherrylist
+ drawvisible
+ return
+ }
+
if {$findstring ne {}} {
if {$gdttype eq [mc "containing:"]} {
if {$highlight_files ne {}} {
@@ -4733,6 +4747,9 @@ proc find_change {name ix op} {
stopfinding
if {$gdttype eq [mc "containing:"]} {
findcom_change
+ } elseif {$gdttype eq [mc "git-cherry between marked commit and:"]} {
+ findcom_change
+ update_gitcherrylist
} else {
if {$highlight_files ne $findstring} {
set highlight_files $findstring
@@ -4742,6 +4759,54 @@ proc find_change {name ix op} {
drawvisible
}
+proc update_gitcherrylist {} {
+ global gitcherryids
+ global markedid
+ global findstring
+ global fstring
+ global currentid
+ global iddrawn
+
+ unset -nocomplain gitcherryids
+ set fs $findstring
+
+ if {$findstring eq {}} {
+ $fstring delete 0 end
+ $fstring insert 0 $currentid
+ }
+
+ if {![info exists markedid]} {
+ error_popup [mc "Please mark a git commit before using this find method!"]
+ return
+ }
+
+ #puts [join [list "Running cherry between: `" $markedid "` and `" $findstring "`"] ""]
+
+ if {[catch {set cherryOutput [exec git cherry $markedid $findstring]}]} {
+ puts "ERROR: An error occured running git-cherry!"
+ return
+ }
+
+ set cherryLines [split $cherryOutput "\n"]
+ foreach cherryLine $cherryLines {
+ set op [lindex [split $cherryLine " "] 0]
+ set gitSha [lindex [split $cherryLine " "] 1]
+
+ #puts [join [list "line is: `" $cherryLine "`, op:`" $op "`, gitSha:`" $gitSha "`"] ""]
+ if {$op eq "+"} {
+ set gitcherryids($gitSha) 1
+ if ([info exists iddrawn($gitSha)]) {
+ bolden $gitSha mainfontbold
+ }
+
+ }
+ }
+ # puts "list is as follows"
+ #foreach {gitsha setBold} [array get gitcherryids] {
+ # puts [concat $gitsha = $setBold]
+ #}
+}
+
proc findcom_change args {
global nhighlights boldnameids
global findpattern findtype findstring gdttype
@@ -4802,6 +4867,9 @@ proc do_file_hl {serial} {
set gdtargs [list "-S$highlight_files"]
} elseif {$gdttype eq [mc "changing lines matching:"]} {
set gdtargs [list "-G$highlight_files"]
+ } elseif {$gdttype eq [mc "git-cherry between marked commit and:"]} {
+ # Skipping opening the file handle, filehighlight
+ return
} else {
# must be "containing:", i.e. we're searching commit info
return
@@ -4882,6 +4950,17 @@ proc doesmatch {f} {
}
}
+proc askcherryhighlight {row id} {
+ global nhighlights gitcherryids
+
+ set isbold 0
+ if {[info exists gitcherryids($id)]} {
+ set isbold 1
+ }
+
+ set nhighlights($id) $isbold
+}
+
proc askfindhighlight {row id} {
global nhighlights commitinfo iddrawn
global findloc
@@ -6216,6 +6295,7 @@ proc drawcmitrow {row} {
global filehighlight fhighlights findpattern nhighlights
global hlview vhighlights
global highlight_related rhighlights
+ global gdttype
if {$row >= $numcommits} return
@@ -6226,6 +6306,11 @@ proc drawcmitrow {row} {
if {[info exists filehighlight] && ![info exists fhighlights($id)]} {
askfilehighlight $row $id
}
+
+ if {$gdttype eq [mc "git-cherry between marked commit and:"] && ![info exists nhighlights($id)]} {
+ askcherryhighlight $row $id
+ }
+
if {$findpattern ne {} && ![info exists nhighlights($id)]} {
askfindhighlight $row $id
}
@@ -6776,7 +6861,9 @@ proc dofind {{dirn 1} {wrap 1}} {
}
set findcurline $findstartline
nowbusy finding [mc "Searching"]
- if {$gdttype ne [mc "containing:"] && ![info exists filehighlight]} {
+ if {$gdttype eq [mc "git-cherry between marked commit and:"]} {
+ # Don't do anything related to open do_file_hl since we'll just have a list
+ } elseif {$gdttype ne [mc "containing:"] && ![info exists filehighlight]} {
after cancel do_file_hl $fh_serial
do_file_hl $fh_serial
}
@@ -6803,6 +6890,7 @@ proc findmore {} {
global findstartline findcurline findallowwrap
global find_dirn gdttype fhighlights fprogcoord
global curview varcorder vrownum varccommits vrowmod
+ global gitcherryids
if {![info exists find_dirn]} {
return 0
@@ -6848,7 +6936,23 @@ proc findmore {} {
set arow [lindex $vrownum($curview) $ai]
set ids [lindex $varccommits($curview,$a)]
set arowend [expr {$arow + [llength $ids]}]
- if {$gdttype eq [mc "containing:"]} {
+
+ if {$gdttype eq [mc "git-cherry between marked commit and:"]} {
+ for {} {$n > 0} {incr n -1; incr l $find_dirn} {
+ if {$l < $arow || $l >= $arowend} {
+ incr ai $find_dirn
+ set a [lindex $varcorder($curview) $ai]
+ set arow [lindex $vrownum($curview) $ai]
+ set ids [lindex $varccommits($curview,$a)]
+ set arowend [expr {$arow + [llength $ids]}]
+ }
+ set id [lindex $ids [expr {$l - $arow}]]
+ if {[info exists gitcherryids($id)]} {
+ set found 1
+ }
+ if {$found} break
+ }
+ } elseif {$gdttype eq [mc "containing:"]} {
for {} {$n > 0} {incr n -1; incr l $find_dirn} {
if {$l < $arow || $l >= $arowend} {
incr ai $find_dirn
--
2.10.2
^ permalink raw reply related
* [PATCH 2/6] Add ability to follow a remote branch with a dialog
From: Pierre Dumuid @ 2016-12-15 11:28 UTC (permalink / raw)
To: paulus, git; +Cc: Pierre Dumuid
In-Reply-To: <20161215112847.14719-1-pmdumuid@gmail.com>
A suggested name is provided when creating a new "following" branch.
Signed-off-by: Pierre Dumuid <pmdumuid@gmail.com>
---
gitk | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 82 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index 50d1ef4..36cba49 100755
--- a/gitk
+++ b/gitk
@@ -2673,6 +2673,7 @@ proc makewindow {} {
{mc "Rename this branch" command mvbranch}
{mc "Remove this branch" command rmbranch}
{mc "Copy branch name" command {clipboard clear; clipboard append $headmenuhead}}
+ {mc "Follow this branch" command follow_remote_branch_dialog}
}
$headctxmenu configure -tearoff 0
@@ -9947,23 +9948,100 @@ proc headmenu {x y id head} {
stopfinding
set headmenuid $id
set headmenuhead $head
- array set state {0 normal 1 normal 2 normal}
+ array set state {0 normal 1 normal 2 normal 3 normal}
if {[string match "remotes/*" $head]} {
set localhead [string range $head [expr [string last / $head] + 1] end]
if {[info exists headids($localhead)]} {
set state(0) disabled
}
- array set state {1 disabled 2 disabled}
+ array set state {1 disabled 2 disabled 3 normal}
}
if {$head eq $mainhead} {
- array set state {0 disabled 2 disabled}
+ array set state {0 disabled 2 disabled 3 disabled}
+ } else {
+ set state(3) disabled
}
- foreach i {0 1 2} {
+ foreach i {0 1 2 3} {
$headctxmenu entryconfigure $i -state $state($i)
}
tk_popup $headctxmenu $x $y
}
+proc follow_remote_branch_dialog {} {
+ global headmenuhead NS
+
+ # check the tree is clean first??
+ nowbusy createFollowingBranch [mc "Creating following branch"]
+ update
+ dohidelocalchanges
+
+ set top .create_following_branch
+ catch {destroy $top}
+ ttk_toplevel $top
+ make_transient $top .
+
+ ${NS}::label $top.title -text [mc "Create following branch"]
+ grid $top.title - -pady 10
+
+ ${NS}::label $top.remote_branch_name_label -text [mc "Remote Branch:"]
+ ${NS}::entry $top.remote_branch_name -width 40
+ $top.remote_branch_name insert 0 $headmenuhead
+ $top.remote_branch_name conf -state readonly
+ grid $top.remote_branch_name_label $top.remote_branch_name -sticky w
+
+ ${NS}::label $top.new_branch_name_label -text [mc "Name:"]
+ ${NS}::entry $top.new_branch_name -width 40
+ set suggested_name $headmenuhead
+ regsub {^remotes/[^/]*/} $suggested_name {} suggested_name
+ $top.new_branch_name insert 0 $suggested_name
+ grid $top.new_branch_name_label $top.new_branch_name -sticky w
+
+ set actionCreate [list follow_remote_branch_callback $top]
+ set actionCancel "catch {notbusy createFollowingBranch; destroy $top}"
+
+ ${NS}::frame $top.buts
+ ${NS}::button $top.buts.go -text [mc "Create"] -command $actionCreate
+ ${NS}::button $top.buts.can -text [mc "Cancel"] -command $actionCancel
+ grid $top.buts.go $top.buts.can
+ grid columnconfigure $top.buts 0 -weight 1 -uniform a
+ grid columnconfigure $top.buts 1 -weight 1 -uniform a
+ grid $top.buts - -pady 10 -sticky ew
+
+ bind $top <Key-Return> $actionCreate
+ bind $top <Key-Escape> $actionCancel
+
+ focus $top.new_branch_name
+}
+
+proc follow_remote_branch_callback {top} {
+ global headids idheads NS
+ set new_branch_name [$top.new_branch_name get]
+ set remote_branch_name [$top.remote_branch_name get]
+ set cmdargs {}
+
+ if {$new_branch_name eq {}} {
+ error_popup [mc "Please specify a name for the new branch"] $top
+ return
+ }
+ if {[info exists headids($new_branch_name)]} {
+ error_popup [mc "The branch name you specified already exists, please specify a new name"] $top
+ return
+ }
+ catch {destroy $top}
+
+ lappend cmdargs $new_branch_name $remote_branch_name
+
+ if {[catch {
+ eval exec git branch --track $cmdargs
+ } err]} {
+ notbusy createFollowingBranch
+ error_popup $err
+ } else {
+ notbusy createFollowingBranch
+ updatecommits
+ }
+}
+
proc cobranch {} {
global headmenuid headmenuhead headids
global showlocalchanges
--
2.10.2
^ permalink raw reply related
* [PATCH 3/6] Add a tree view to the local branches, remote branches and tags, where / is treated as a directory seperator.
From: Pierre Dumuid @ 2016-12-15 11:28 UTC (permalink / raw)
To: paulus, git; +Cc: Pierre Dumuid
In-Reply-To: <20161215112847.14719-1-pmdumuid@gmail.com>
Signed-off-by: Pierre Dumuid <pmdumuid@gmail.com>
---
gitk | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 117 insertions(+)
diff --git a/gitk b/gitk
index 36cba49..a894f1d 100755
--- a/gitk
+++ b/gitk
@@ -2089,6 +2089,10 @@ proc makewindow {} {
{mc "Reread re&ferences" command rereadrefs}
{mc "&List references" command showrefs -accelerator F2}
{xx "" separator}
+ {mc "List Local Branches" command {show_tree_of_references_dialog "localBranches"} -accelerator F6}
+ {mc "List Remote Branches" command {show_tree_of_references_dialog "remoteBranches"} -accelerator F7}
+ {mc "List Tags" command {show_tree_of_references_dialog "tags"} -accelerator F8}
+ {xx "" separator}
{mc "Start git &gui" command {exec git gui &}}
{xx "" separator}
{mc "&Quit" command doquit -accelerator Meta1-Q}
@@ -2601,6 +2605,9 @@ proc makewindow {} {
bind . <F5> updatecommits
bindmodfunctionkey Shift 5 reloadcommits
bind . <F2> showrefs
+ bind . <F6> {show_tree_of_references_dialog "localBranches"}
+ bind . <F7> {show_tree_of_references_dialog "remoteBranches"}
+ bind . <F8> {show_tree_of_references_dialog "tags"}
bindmodfunctionkey Shift 4 {newview 0}
bind . <F4> edit_or_newview
bind . <$M1B-q> doquit
@@ -10146,6 +10153,116 @@ proc rmbranch {} {
run refill_reflist
}
+# Display a tree view of local branches, remote branches, and tags according to view_type.
+#
+# @param string view_type
+# Must be one of "localBranches", "remoteBranches", or "tags".
+#
+proc show_tree_of_references_dialog {view_type} {
+ global NS
+ global treefilelist
+ global headids tagids
+
+ switch -- $view_type {
+ "localBranches" {
+ set dialogName "Local Branches"
+ set top .show_tree_of_local_branches
+ set listOfReferences [lsort [array names headids -regexp {^(?!remotes/)} ]]
+ set truncateFrom 0
+ }
+ "remoteBranches" {
+ set dialogName "Remote Branches"
+ set top .show_tree_of_remote_branches
+ set listOfReferences [lsort [array names headids -regexp {^remotes/} ]]
+ set truncateFrom 8
+ }
+ "tags" {
+ set dialogName "Tags"
+ set top .show_tree_of_tags
+ set listOfReferences [lsort [array names tagids]]
+ set truncateFrom 0
+ }
+ }
+
+ if {[winfo exists $top]} {
+ raise $top
+ return
+ }
+
+ ttk_toplevel $top
+ wm title $top [mc "$dialogName: %s" [file tail [pwd]]]
+ wm geometry $top "600x900"
+
+ make_transient $top .
+
+ ## See http://www.tkdocs.com/tutorial/tree.html
+ ttk::treeview $top.referenceList -xscrollcommand "$top.horizontalScrollBar set" -yscrollcommand "$top.verticalScrollBar set"
+
+ # Populate the dialog
+ foreach reference $listOfReferences {
+ # The display name omits some leading characters (such as "remotes/")
+ set referenceDisplayName [string range $reference $truncateFrom end]
+
+ # Split the branch/tag by slashes, and incrementally ensure that each leaf in the treeview exists..
+ # otherwise add it.
+ set treeLeaves [split $referenceDisplayName "/"]
+ for {set i 0} {$i < [llength $treeLeaves]} {} {
+ set leafReferenceId [join [lrange $treeLeaves 0 $i] "/"]
+ if {![$top.referenceList exists $leafReferenceId]} {
+ if {$i > 0} {
+ set parentLeafId [join [lrange $treeLeaves 0 $i-1] "/"]
+ } else {
+ set parentLeafId {}
+ }
+ $top.referenceList insert $parentLeafId end -id $leafReferenceId -text [lindex $treeLeaves $i]
+ }
+ incr i
+ }
+ }
+
+ ${NS}::scrollbar $top.verticalScrollBar -command "$top.referenceList yview" -orient vertical
+ ${NS}::scrollbar $top.horizontalScrollBar -command "$top.referenceList xview" -orient horizontal
+
+ grid $top.referenceList $top.verticalScrollBar -sticky nsew
+ grid $top.horizontalScrollBar x -sticky ew
+
+ bind $top <Key-Escape> [list destroy $top]
+
+ bind $top.referenceList <<TreeviewSelect>> {callback_tree_of_references_item_selected %W; break}
+
+ grid columnconfigure $top 0 -weight 1
+ grid rowconfigure $top 0 -weight 1
+}
+
+# Call back for selecting a branch / tag in the tree of references
+#
+# @param w
+#
+proc callback_tree_of_references_item_selected {w} {
+ global headids tagids
+
+ set itemId [$w focus]
+ switch -- $w {
+ ".show_tree_of_local_branches.referenceList" {
+ if {[info exists headids($itemId)]} {
+ selbyid $headids($itemId)
+ }
+ }
+ ".show_tree_of_remote_branches.referenceList" {
+ set itemId "remotes/$itemId"
+ if {[info exists headids($itemId)]} {
+ selbyid $headids($itemId)
+ }
+ }
+ ".show_tree_of_tags.referenceList" {
+ if {[info exists tagids($itemId)]} {
+ selbyid $tagids($itemId)
+ }
+ }
+ }
+}
+
+
# Display a list of tags and heads
proc showrefs {} {
global showrefstop bgcolor fgcolor selectbgcolor NS
--
2.10.2
^ permalink raw reply related
* [PATCH 5/6] gitk: Add a "Save file as" menu item
From: Pierre Dumuid @ 2016-12-15 11:28 UTC (permalink / raw)
To: paulus, git; +Cc: Pierre Dumuid, Andreas Amann
In-Reply-To: <20161215112847.14719-1-pmdumuid@gmail.com>
Previously, there was no easy way to save a particular file from the
currently selected revision.
This patch adds a menu item "Save file as" to the file list popup
menu, which opens a file selection dialog to determine the name under
which a file should be saved. The default filename is of the form
"[shortid] basename". If the current revision is the index, the
default pattern is of the form "[index] basename". This works for
both, the "Patch" and "Tree" view. The menu item is disabled for the
"local uncommitted changes" fake revision.
Signed-off-by: Andreas Amann <andreas.amann@web.de>
Signed-off-by: Pierre Dumuid <pmdumuid@gmail.com>
---
gitk | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/gitk b/gitk
index 5f27716..0903d2d 100755
--- a/gitk
+++ b/gitk
@@ -2693,6 +2693,7 @@ proc makewindow {} {
{mc "Highlight this too" command {flist_hl 0}}
{mc "Highlight this only" command {flist_hl 1}}
{mc "External diff" command {external_diff}}
+ {mc "Save file as" command {save_file_as}}
{mc "Blame parent commit" command {external_blame 1}}
{mc "Copy path" command {clipboard clear; clipboard append $flist_menu_file}}
}
@@ -3504,6 +3505,7 @@ proc sel_flist {w x y} {
proc pop_flist_menu {w X Y x y} {
global ctext cflist cmitmode flist_menu flist_menu_file
global treediffs diffids
+ global nullid
stopfinding
set l [lindex [split [$w index "@$x,$y"] "."] 0]
@@ -3521,6 +3523,12 @@ proc pop_flist_menu {w X Y x y} {
}
# Disable "External diff" item in tree mode
$flist_menu entryconf 2 -state $xdiffstate
+ set savefilestate "normal"
+ if {[lindex $diffids 0] eq $nullid} {
+ set savefilestate "disabled"
+ }
+ # Disable "Save file as" item "local uncommited changes" revision
+ $flist_menu entryconf 3 -state $savefilestate
tk_popup $flist_menu $X $Y
}
@@ -3632,6 +3640,34 @@ proc external_diff_get_one_file {diffid filename diffdir} {
"revision $diffid"]
}
+proc save_file_as {} {
+ global nullid nullid2
+ global flist_menu_file cmitmode
+ global diffids
+
+ set diffid [lindex $diffids 0]
+ if {$diffid == $nullid} {
+ return
+ } elseif {$diffid == $nullid2} {
+ set diffidtext [mc "index"]
+ set diffid ""
+ set whattext $diffidtext
+ } else {
+ set diffidtext [shortids $diffid]
+ set whattext "[mc "revision"] $diffidtext"
+ }
+ set diffid $diffid:
+ if {$cmitmode eq "tree"} {
+ set diffid $diffid./
+ }
+ set difffile "\[$diffidtext\] [file tail $flist_menu_file]"
+ set difffile [tk_getSaveFile -initialfile $difffile -title [mc "Save file as"] -parent .]
+ if {$difffile eq {}} {
+ return
+ }
+ save_file_from_commit $diffid$flist_menu_file $difffile $whattext
+}
+
proc external_diff {} {
global nullid nullid2
global flist_menu_file
--
2.10.2
^ permalink raw reply related
* [PATCH 6/6] Rename 'remotes/' to 'r../' in heads
From: Pierre Dumuid @ 2016-12-15 11:28 UTC (permalink / raw)
To: paulus, git; +Cc: Pierre Dumuid
In-Reply-To: <20161215112847.14719-1-pmdumuid@gmail.com>
Signed-off-by: Pierre Dumuid <pmdumuid@gmail.com>
---
gitk | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/gitk b/gitk
index 0903d2d..6f50b06 100755
--- a/gitk
+++ b/gitk
@@ -6731,22 +6731,28 @@ proc drawtags {id x xt y1} {
set yb [expr {$yt + $linespc - 1}]
set xvals {}
set wvals {}
+ set newTags {}
+
set i -1
foreach tag $marks {
incr i
+ set newTag $tag
+ regsub {^remotes} $newTag "r.." newTag
+
if {$i >= $ntags && $i < $ntags + $nheads && $tag eq $mainhead} {
- set wid [font measure mainfontbold $tag]
+ set wid [font measure mainfontbold $newTag]
} else {
- set wid [font measure mainfont $tag]
+ set wid [font measure mainfont $newTag]
}
lappend xvals $xt
lappend wvals $wid
+ lappend newTags $newTag
set xt [expr {$xt + $wid + $extra}]
}
set t [$canv create line $x $y1 [lindex $xvals end] $y1 \
-width $lthickness -fill $reflinecolor -tags tag.$id]
$canv lower $t
- foreach tag $marks x $xvals wid $wvals {
+ foreach tag $marks x $xvals wid $wvals newTag $newTags {
set tag_quoted [string map {% %%} $tag]
set xl [expr {$x + $delta}]
set xr [expr {$x + $delta + $wid + $lthickness}]
@@ -6778,7 +6784,10 @@ proc drawtags {id x xt y1} {
$canv create polygon $x $yt $xr $yt $xr $yb $x $yb \
-width 1 -outline black -fill $col -tags tag.$id
if {[regexp {^(remotes/.*/|remotes/)} $tag match remoteprefix]} {
- set rwid [font measure mainfont $remoteprefix]
+ set newRemotePrefix $remoteprefix
+ regsub {^remotes} $newRemotePrefix "r.." newRemotePrefix
+
+ set rwid [font measure mainfont $newRemotePrefix]
set xi [expr {$x + 1}]
set yti [expr {$yt + 1}]
set xri [expr {$x + $rwid}]
@@ -6786,7 +6795,7 @@ proc drawtags {id x xt y1} {
-width 0 -fill $remotebgcolor -tags tag.$id
}
}
- set t [$canv create text $xl $y1 -anchor w -text $tag -fill $headfgcolor \
+ set t [$canv create text $xl $y1 -anchor w -text $newTag -fill $headfgcolor \
-font $font -tags [list tag.$id text]]
if {$ntags >= 0} {
$canv bind $t <1> $tagclick
--
2.10.2
^ permalink raw reply related
* [PATCH 4/6] Add DirDiffTool as additional option
From: Pierre Dumuid @ 2016-12-15 11:28 UTC (permalink / raw)
To: paulus, git; +Cc: Pierre Dumuid
In-Reply-To: <20161215112847.14719-1-pmdumuid@gmail.com>
Signed-off-by: Pierre Dumuid <pmdumuid@gmail.com>
---
gitk | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/gitk b/gitk
index a894f1d..5f27716 100755
--- a/gitk
+++ b/gitk
@@ -2661,6 +2661,9 @@ proc makewindow {} {
{mc "Diff this -> marked commit" command {diffvsmark 0}}
{mc "Diff marked commit -> this" command {diffvsmark 1}}
{mc "Revert this commit" command revert}
+
+ {mc "DirDiffTool this -> selected" command {externalDiffToolVsSel 0}}
+ {mc "DirDiffTool selected -> this" command {externalDiffToolVsSel 1}}
}
$rowctxmenu configure -tearoff 0
@@ -9254,6 +9257,20 @@ proc diffvssel {dirn} {
doseldiff $oldid $newid
}
+proc externalDiffToolVsSel {diffDirection} {
+ global rowmenuid selectedline
+
+ if {$selectedline eq {}} return
+ if {$diffDirection} {
+ set oldid [commitonrow $selectedline]
+ set newid $rowmenuid
+ } else {
+ set oldid $rowmenuid
+ set newid [commitonrow $selectedline]
+ }
+ [exec git difftool -d $oldid $newid]
+}
+
proc diffvsmark {dirn} {
global rowmenuid markedid
--
2.10.2
^ permalink raw reply related
* Additional git hooks
From: Chiel ten Brinke @ 2016-12-15 13:57 UTC (permalink / raw)
To: git
Would patches introducing new git hooks, e.g. for post-fetch, be
eligible for acceptance?
If a more detailed explanation about a specific use case is required,
I'd be happy to provide it.
Btw, the link in the README
http://news.gmane.org/gmane.comp.version-control.git/ is dead.
Chiel
^ permalink raw reply
* Re: Additional git hooks
From: Jeff King @ 2016-12-15 14:14 UTC (permalink / raw)
To: Chiel ten Brinke; +Cc: git
In-Reply-To: <CAFw20syajXbjCQRcrqCv8pS9JwSge7-V4Hsg96n8SpYv2jJneQ@mail.gmail.com>
On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote:
> Would patches introducing new git hooks, e.g. for post-fetch, be
> eligible for acceptance?
The general guidelines for adding hooks is laid out here:
http://public-inbox.org/git/7vbq7ibxhh.fsf@gitster.siamese.dyndns.org/
-Peff
^ permalink raw reply
* [PATCH] README: replace gmane link with public-inbox
From: Jeff King @ 2016-12-15 14:17 UTC (permalink / raw)
To: Chiel ten Brinke; +Cc: git
In-Reply-To: <CAFw20syajXbjCQRcrqCv8pS9JwSge7-V4Hsg96n8SpYv2jJneQ@mail.gmail.com>
On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote:
> Btw, the link in the README
> http://news.gmane.org/gmane.comp.version-control.git/ is dead.
Yes, the status of gmane was up in the air for a while, but I think we
can give it up as dead now (at least for our purposes).
-- >8 --
Subject: README: replace gmane link with public-inbox
The general status and future of gmane is unclear at this
point, but certainly it does not seem to be carrying
gmane.comp.version-control.git at all anymore. Let's point
to public-inbox.org, which seems to be the favored archive
on the list these days (and which uses message-ids in its
URLs, making the links somewhat future-proof).
Reported-by: Chiel ten Brinke <ctenbrinke@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README.md b/README.md
index bd8a918a9..c0cd5580e 100644
--- a/README.md
+++ b/README.md
@@ -33,7 +33,7 @@ requests, comments and patches to git@vger.kernel.org (read
[Documentation/SubmittingPatches][] for instructions on patch submission).
To subscribe to the list, send an email with just "subscribe git" in
the body to majordomo@vger.kernel.org. The mailing list archives are
-available at http://news.gmane.org/gmane.comp.version-control.git/,
+available at https://public-inbox.org/git,
http://marc.info/?l=git and other archival sites.
The maintainer frequently sends the "What's cooking" reports that
--
2.11.0.348.g960a0b554
^ permalink raw reply related
* Re: Additional git hooks
From: Jeff King @ 2016-12-15 14:19 UTC (permalink / raw)
To: Chiel ten Brinke; +Cc: git
In-Reply-To: <20161215141430.natk4mi7imixcoow@sigill.intra.peff.net>
On Thu, Dec 15, 2016 at 09:14:30AM -0500, Jeff King wrote:
> On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote:
>
> > Would patches introducing new git hooks, e.g. for post-fetch, be
> > eligible for acceptance?
>
> The general guidelines for adding hooks is laid out here:
>
> http://public-inbox.org/git/7vbq7ibxhh.fsf@gitster.siamese.dyndns.org/
One interesting follow-up, though (which seems sensible to me):
http://public-inbox.org/git/7vr5fraxbf.fsf@alter.siamese.dyndns.org/
-Peff
^ permalink raw reply
* [PATCH] git-p4: Fix multi-path changelist empty commits
From: George Vanburgh @ 2016-12-15 17:14 UTC (permalink / raw)
To: git
From: George Vanburgh <gvanburgh@bloomberg.net>
When importing from multiple perforce paths - we may attempt to import a changelist that contains files from two (or more) of these depot paths. Currently, this results in multiple git commits - one containing the changes, and the other(s) as empty commits. This behavior was introduced in commit 1f90a64 ("git-p4: reduce number of server queries for fetches", 2015-12-19).
Reproduction Steps:
1. Have a git repo cloned from a perforce repo using multiple depot paths (e.g. //depot/foo and //depot/bar).
2. Submit a single change to the perforce repo that makes changes in both //depot/foo and //depot/bar.
3. Run "git p4 sync" to sync the change from #2.
Change is synced as multiple commits, one for each depot path that was affected.
Using a set, instead of a list inside p4ChangesForPaths() ensures that each changelist is unique to the returned list, and therefore only a single commit is generated for each changelist.
Reported-by: James Farwell <jfarwell@vmware.com>
Signed-off-by: George Vanburgh <gvanburgh@bloomberg.net>
---
git-p4.py | 4 ++--
t/t9800-git-p4-basic.sh | 22 +++++++++++++++++++++-
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index fd5ca52..6307bc8 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -822,7 +822,7 @@ def p4ChangesForPaths(depotPaths, changeRange, requestedBlockSize):
die("cannot use --changes-block-size with non-numeric revisions")
block_size = None
- changes = []
+ changes = set()
# Retrieve changes a block at a time, to prevent running
# into a MaxResults/MaxScanRows error from the server.
@@ -841,7 +841,7 @@ def p4ChangesForPaths(depotPaths, changeRange, requestedBlockSize):
# Insert changes in chronological order
for line in reversed(p4_read_pipe_lines(cmd)):
- changes.append(int(line.split(" ")[1]))
+ changes.add(int(line.split(" ")[1]))
if not block_size:
break
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 0730f18..4d72e0b 100755
--- a/t/t9800-git-p4-basic.sh
+++ b/t/t9800-git-p4-basic.sh
@@ -131,6 +131,26 @@ test_expect_success 'clone two dirs, @all, conflicting files' '
)
'
+test_expect_success 'clone two dirs, each edited by submit, single git commit' '
+ (
+ cd "$cli" &&
+ echo sub1/f4 >sub1/f4 &&
+ p4 add sub1/f4 &&
+ echo sub2/f4 >sub2/f4 &&
+ p4 add sub2/f4 &&
+ p4 submit -d "sub1/f4 and sub2/f4"
+ ) &&
+ git p4 clone --dest="$git" //depot/sub1@all //depot/sub2@all &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git"
+ git ls-files >lines &&
+ test_line_count = 4 lines &&
+ git log --oneline p4/master >lines &&
+ test_line_count = 5 lines
+ )
+'
+
revision_ranges="2000/01/01,#head \
1,2080/01/01 \
2000/01/01,2080/01/01 \
@@ -147,7 +167,7 @@ test_expect_success 'clone using non-numeric revision ranges' '
(
cd "$git" &&
git ls-files >lines &&
- test_line_count = 6 lines
+ test_line_count = 8 lines
)
done
'
--
https://github.com/git/git/pull/311
^ permalink raw reply related
* Re: [PATCH v10 2/6] http: always warn if libcurl version is too old
From: Junio C Hamano @ 2016-12-15 17:29 UTC (permalink / raw)
To: Jeff King; +Cc: Brandon Williams, git, sbeller, bburky, jrnieder
In-Reply-To: <20161215002120.xlnlquuqqw25wngc@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Dec 14, 2016 at 02:39:51PM -0800, Brandon Williams wrote:
>
>> Always warn if libcurl version is too old because:
>>
>> 1. Even without a protocol whitelist, newer versions of curl have all
>> non-http protocols disabled by default.
>
> Technically, non-http and non-ftp. Maybe just "non-standard" would be
> more accurate.
>
> Not worth a re-roll, but if Junio hasn't applied yet, maybe worth fixing
> up while applying.
I just did a "rebase -i"; thanks always for your careful reading.
^ permalink raw reply
* Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'
From: Junio C Hamano @ 2016-12-15 17:36 UTC (permalink / raw)
To: Chris Packham; +Cc: GIT, Markus Hitter, Jeff King, Jacob Keller
In-Reply-To: <CAFOYHZD_mFMvggq4pedjGCz332i1-VcRKxu30iMzURfB3Mu8Vg@mail.gmail.com>
Chris Packham <judge.packham@gmail.com> writes:
> On Thu, Dec 15, 2016 at 7:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> The last one 3/3 is a nice touch that makes sure that we do not
>> forget what we discovered during the discussion. Very much
>> appreciated.
>>
>> Will queue. Thanks.
>
> Did you want me to send a v4 to mark the strings for translation or
> will you apply a fixup your end?
I didn't follow the _() discussion (was there any?)
I do not think lack of _() is a show-stopper and my preference is to
keep what I queued that does not have _(), and receive a separate
follow-up patch that changes "msg" to _("msg") and does nothing
else.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] fix pushing to //server/share/dir on Windows
From: Junio C Hamano @ 2016-12-15 17:49 UTC (permalink / raw)
To: Jeff King
Cc: Torsten Bögershausen, Johannes Sixt, Johannes Schindelin,
Git Mailing List
In-Reply-To: <20161215110155.it7ptkbju5etmnpn@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I don't have an opinion either way on what Windows would want, but note
> that the function already _does_ convert separators to slashes. With
> Johannes's original patch, you'd end up with a mix, like:
>
> \\server\share/dir1/file
>
> So this conversion is really just retaining the original behavior, and
> making it consistent throughout the path.
>
> Which isn't to say that the function as it currently exists isn't a
> little bit buggy. :)
>
> One of the points of normalizing, though, is that Git can then do
> textual comparisons between the output. So I think there's value in
> having a canonical internal representation, even if the OS could handle
> more exotic ones.
E.g. the log message of d53c2c6738 ("mingw: fix t9700's assumption
about directory separators", 2016-01-27) says the two kinds of
slashes are equivalent over there, but the patch text ends up doing
exactly that normalization.
5ca6b7bb47 ("config --show-origin: report paths with forward
slashes", 2016-03-23) is an example of us trying to normalize in
order to give consistent output to the users.
Having said all that, I do not have an opinion either way on what
Windows would want, either ;-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox