* Re: [RFC/PATCH] Option to revert order of parents in merge commit
From: Junio C Hamano @ 2012-11-24 2:58 UTC (permalink / raw)
To: Kacper Kornet; +Cc: git
In-Reply-To: <20121123083550.GA702@camk.edu.pl>
Kacper Kornet <draenog@pld-linux.org> writes:
> The following patch is an attempt to implement this idea.
I think "revert" is a wrong word (implying you have already done
something and you are trying to defeat the effect of that old
something), and you meant to say "reverse" (i.e. the opposite of
normal) or something.
I am unsure about the usefulness of this, though.
After completing a topic on branch A, you would merge it to your own
copy of the integration branch (e.g. 'master') and try to push,
which may be rejected due to non-fast-forwardness:
$ git checkout master
$ git merge A
$ git push
At that point, if you _care_ about the merge parent order, you could
do this (still on 'master'):
$ git fetch origin
$ git reset --hard origin/master
$ git merge A
$ test test test
$ git push
With --reverse-parents, it would become:
$ git pull --reverse-parents
$ test test test
$ git push
which certainly is shorter and looks simpler. The workflow however
would encourage people to work directly on the master branch, which
is a bit of downside.
Is there any interaction between this "pull --reverse-parents"
change and possible conflict resolution when the command stops and
asks the user for help? For example, whom should "--ours" and "-X
ours" refer to? Us, or the upstream?
^ permalink raw reply
* Re: [PATCH v2 0/4] nd/unify-appending-of-s-o-b
From: Junio C Hamano @ 2012-11-24 2:05 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1353602289-9418-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This round cherry-pick and commit only skip S-o-b if the last one is
> the same...
That sounds sensible. When the user asks us to add sign-off, we
should honor it, unless it is known that adding one is absolutely
unnecessary, which is "it already exists as the last one". Ignoring
all other cases will lose information.
Among the non-merge commits in the kernel history, you see about 500
such commits where the same contributor signs off the patch more
than once, recording the flow of the patch; 106a4ee258 seems to be
the most recent example.
Thanks.
^ permalink raw reply
* [PATCH 6/6] git p4: remove unneeded cmd initialization
From: Pete Wyckoff @ 2012-11-23 22:35 UTC (permalink / raw)
To: git
In-Reply-To: <1353710139-16207-1-git-send-email-pw@padd.com>
It confuses pylint, and is never needed.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
git-p4.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index 9712082..551aec9 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -3188,7 +3188,6 @@ def main():
printUsage(commands.keys())
sys.exit(2)
- cmd = ""
cmdName = sys.argv[1]
try:
klass = commands[cmdName]
--
1.8.0.276.gd9397fc
^ permalink raw reply related
* [PATCH 5/6] git p4: fix labelDetails typo in exception
From: Pete Wyckoff @ 2012-11-23 22:35 UTC (permalink / raw)
To: git
In-Reply-To: <1353710139-16207-1-git-send-email-pw@padd.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
git-p4.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index cb1ec8d..9712082 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2406,7 +2406,7 @@ class P4Sync(Command, P4UserMap):
try:
tmwhen = time.strptime(labelDetails['Update'], "%Y/%m/%d %H:%M:%S")
except ValueError:
- print "Could not convert label time %s" % labelDetail['Update']
+ print "Could not convert label time %s" % labelDetails['Update']
tmwhen = 1
when = int(time.mktime(tmwhen))
--
1.8.0.276.gd9397fc
^ permalink raw reply related
* [PATCH 4/6] git p4 test: display unresolvable host error
From: Pete Wyckoff @ 2012-11-23 22:35 UTC (permalink / raw)
To: git
In-Reply-To: <1353710139-16207-1-git-send-email-pw@padd.com>
This test passes already. Make sure p4 diagnostic errors are displayed.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9800-git-p4-basic.sh | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 05797c3..8c59796 100755
--- a/t/t9800-git-p4-basic.sh
+++ b/t/t9800-git-p4-basic.sh
@@ -183,6 +183,18 @@ test_expect_success 'initial import time from top change time' '
)
'
+test_expect_success 'unresolvable host in P4PORT should display error' '
+ test_when_finished cleanup_git &&
+ git p4 clone --dest="$git" //depot &&
+ (
+ cd "$git" &&
+ P4PORT=nosuchhost:65537 &&
+ export P4PORT &&
+ test_expect_code 1 git p4 sync >out 2>err &&
+ grep "connect to nosuchhost" err
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.8.0.276.gd9397fc
^ permalink raw reply related
* [PATCH 3/6] git p4: catch p4 errors when streaming file contents
From: Pete Wyckoff @ 2012-11-23 22:35 UTC (permalink / raw)
To: git
In-Reply-To: <1353710139-16207-1-git-send-email-pw@padd.com>
Error messages that arise during the "p4 print" phase of
generating commits were silently ignored. Catch them,
abort the fast-import, and exit.
Without this fix, the sync/clone appears to work, but files that
are inaccessible by the p4d server will still be imported to git,
although without the proper contents. Instead the errant files
will contain a p4 error message, such as "Librarian checkout
//depot/path failed".
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
git-p4.py | 38 +++++++++++++++++++++++++++++++-------
t/t9800-git-p4-basic.sh | 13 ++++++++++++-
2 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 9644c9f..cb1ec8d 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2139,6 +2139,29 @@ class P4Sync(Command, P4UserMap):
# handle another chunk of streaming data
def streamP4FilesCb(self, marshalled):
+ # catch p4 errors and complain
+ err = None
+ if "code" in marshalled:
+ if marshalled["code"] == "error":
+ if "data" in marshalled:
+ err = marshalled["data"].rstrip()
+ if err:
+ f = None
+ if self.stream_have_file_info:
+ if "depotFile" in self.stream_file:
+ f = self.stream_file["depotFile"]
+ # force a failure in fast-import, else an empty
+ # commit will be made
+ self.gitStream.write("\n")
+ self.gitStream.write("die-now\n")
+ self.gitStream.close()
+ # ignore errors, but make sure it exits first
+ self.importProcess.wait()
+ if f:
+ die("Error from p4 print for %s: %s" % (f, err))
+ else:
+ die("Error from p4 print: %s" % err)
+
if marshalled.has_key('depotFile') and self.stream_have_file_info:
# start of a new file - output the old one first
self.streamOneP4File(self.stream_file, self.stream_contents)
@@ -2900,12 +2923,13 @@ class P4Sync(Command, P4UserMap):
self.tz = "%+03d%02d" % (- time.timezone / 3600, ((- time.timezone % 3600) / 60))
- importProcess = subprocess.Popen(["git", "fast-import"],
- stdin=subprocess.PIPE, stdout=subprocess.PIPE,
- stderr=subprocess.PIPE);
- self.gitOutput = importProcess.stdout
- self.gitStream = importProcess.stdin
- self.gitError = importProcess.stderr
+ self.importProcess = subprocess.Popen(["git", "fast-import"],
+ stdin=subprocess.PIPE,
+ stdout=subprocess.PIPE,
+ stderr=subprocess.PIPE);
+ self.gitOutput = self.importProcess.stdout
+ self.gitStream = self.importProcess.stdin
+ self.gitError = self.importProcess.stderr
if revision:
self.importHeadRevision(revision)
@@ -2965,7 +2989,7 @@ class P4Sync(Command, P4UserMap):
self.importP4Labels(self.gitStream, missingP4Labels)
self.gitStream.close()
- if importProcess.wait() != 0:
+ if self.importProcess.wait() != 0:
die("fast-import failed: %s" % self.gitError.read())
self.gitOutput.close()
self.gitError.close()
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index b7ad716..05797c3 100755
--- a/t/t9800-git-p4-basic.sh
+++ b/t/t9800-git-p4-basic.sh
@@ -143,7 +143,18 @@ test_expect_success 'exit when p4 fails to produce marshaled output' '
! test_i18ngrep Traceback errs
'
-test_expect_success 'clone bare' '
+# Hide a file from p4d, make sure we catch its complaint. This won't fail in
+# p4 changes, files, or describe; just in p4 print. If P4CLIENT is unset, the
+# message will include "Librarian checkout".
+test_expect_success 'exit gracefully for p4 server errors' '
+ test_when_finished "mv \"$db\"/depot/file1,v,hidden \"$db\"/depot/file1,v" &&
+ mv "$db"/depot/file1,v "$db"/depot/file1,v,hidden &&
+ test_when_finished cleanup_git &&
+ test_expect_code 1 git p4 clone --dest="$git" //depot@1 >out 2>err &&
+ test_i18ngrep "Error from p4 print" err
+'
+
+test_expect_success 'clone --bare should make a bare repository' '
rm -rf "$git" &&
git p4 clone --dest="$git" --bare //depot &&
test_when_finished cleanup_git &&
--
1.8.0.276.gd9397fc
^ permalink raw reply related
* [PATCH 2/6] git p4: handle servers without move support
From: Pete Wyckoff @ 2012-11-23 22:35 UTC (permalink / raw)
To: git
In-Reply-To: <1353710139-16207-1-git-send-email-pw@padd.com>
Support for the "p4 move" command was added in 8e9497c (git p4:
add support for 'p4 move' in P4Submit, 2012-07-12), which checks
to make sure that the client and server support the command.
But older versions of p4d may not handle the "-k" argument, and
newer p4d allow disabling "p4 move" with a configuration setting.
Check for both these cases by testing a p4 move command on bogus
filenames and looking for strings in the error messages.
Reported-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
git-p4.py | 21 ++++++++++++++++++++-
t/t9814-git-p4-rename.sh | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index cd68e04..9644c9f 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -129,6 +129,25 @@ def p4_has_command(cmd):
p.communicate()
return p.returncode == 0
+def p4_has_move_command():
+ """See if the move command exists, that it supports -k, and that
+ it has not been administratively disabled. The arguments
+ must be correct, but the filenames do not have to exist. Use
+ ones with wildcards so even if they exist, it will fail."""
+
+ if not p4_has_command("move"):
+ return False
+ cmd = p4_build_cmd(["move", "-k", "@from", "@to"])
+ p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+ (out, err) = p.communicate()
+ # return code will be 1 in either case
+ if err.find("Invalid option") >= 0:
+ return False
+ if err.find("disabled") >= 0:
+ return False
+ # assume it failed because @... was invalid changelist
+ return True
+
def system(cmd):
expand = isinstance(cmd,basestring)
if verbose:
@@ -894,7 +913,7 @@ class P4Submit(Command, P4UserMap):
self.conflict_behavior = None
self.isWindows = (platform.system() == "Windows")
self.exportLabels = False
- self.p4HasMoveCommand = p4_has_command("move")
+ self.p4HasMoveCommand = p4_has_move_command()
def check(self):
if len(p4CmdList("opened ...")) > 0:
diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 3bf1224..be802e0 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -199,6 +199,41 @@ test_expect_success 'detect copies' '
)
'
+# See if configurables can be set, and in particular if the run.move.allow
+# variable exists, which allows admins to disable the "p4 move" command.
+test_expect_success 'p4 configure command and run.move.allow are available' '
+ p4 configure show run.move.allow >out ; retval=$? &&
+ test $retval = 0 &&
+ {
+ egrep ^run.move.allow: out &&
+ test_set_prereq P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW ||
+ true
+ } || true
+'
+
+# If move can be disabled, turn it off and test p4 move handling
+test_expect_success P4D_HAVE_CONFIGURABLE_RUN_MOVE_ALLOW \
+ 'do not use p4 move when administratively disabled' '
+ test_when_finished "p4 configure set run.move.allow=1" &&
+ p4 configure set run.move.allow=0 &&
+ (
+ cd "$cli" &&
+ echo move-disallow-file >move-disallow-file &&
+ p4 add move-disallow-file &&
+ p4 submit -d "add move-disallow-file"
+ ) &&
+ test_when_finished cleanup_git &&
+ git p4 clone --dest="$git" //depot &&
+ (
+ cd "$git" &&
+ git config git-p4.skipSubmitEdit true &&
+ git config git-p4.detectRenames true &&
+ git mv move-disallow-file move-disallow-file-moved &&
+ git commit -m "move move-disallow-file" &&
+ git p4 submit
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.8.0.276.gd9397fc
^ permalink raw reply related
* [PATCH 1/6] git p4: catch p4 describe errors
From: Pete Wyckoff @ 2012-11-23 22:35 UTC (permalink / raw)
To: git
In-Reply-To: <1353710139-16207-1-git-send-email-pw@padd.com>
Group the two calls to "p4 describe" into a new helper function,
and try to validate the p4 results. The current behavior when p4
describe fails is to die with a python backtrace. The new behavior
will print the full response.
This does not solve any particular problem, but adds more
checking in hopes of narrowing down odd behavior seen on
at least two occasions.
Based-on-patch-by: Matt Arsenault <arsenm2@gmail.com>
Reported-by: Arthur <a.foulon@amesys.fr>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
git-p4.py | 35 ++++++++++++++++++++++++++---------
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 7d6c928..cd68e04 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -169,6 +169,29 @@ def p4_reopen(type, f):
def p4_move(src, dest):
p4_system(["move", "-k", wildcard_encode(src), wildcard_encode(dest)])
+def p4_describe(change):
+ """Make sure it returns a valid result by checking for
+ the presence of field "time". Return a dict of the
+ results."""
+
+ ds = p4CmdList(["describe", "-s", str(change)])
+ if len(ds) != 1:
+ die("p4 describe -s %d did not return 1 result: %s" % (change, str(ds)))
+
+ d = ds[0]
+
+ if "p4ExitCode" in d:
+ die("p4 describe -s %d exited with %d: %s" % (change, d["p4ExitCode"],
+ str(d)))
+ if "code" in d:
+ if d["code"] == "error":
+ die("p4 describe -s %d returned error code: %s" % (change, str(d)))
+
+ if "time" not in d:
+ die("p4 describe -s %d returned no \"time\": %s" % (change, str(d)))
+
+ return d
+
#
# Canonicalize the p4 type and return a tuple of the
# base type, plus any modifiers. See "p4 help filetypes"
@@ -2543,7 +2566,7 @@ class P4Sync(Command, P4UserMap):
def importChanges(self, changes):
cnt = 1
for change in changes:
- description = p4Cmd(["describe", str(change)])
+ description = p4_describe(change)
self.updateOptionDict(description)
if not self.silent:
@@ -2667,14 +2690,8 @@ class P4Sync(Command, P4UserMap):
# Use time from top-most change so that all git p4 clones of
# the same p4 repo have the same commit SHA1s.
- res = p4CmdList("describe -s %d" % newestRevision)
- newestTime = None
- for r in res:
- if r.has_key('time'):
- newestTime = int(r['time'])
- if newestTime is None:
- die("\"describe -s\" on newest change %d did not give a time")
- details["time"] = newestTime
+ res = p4_describe(newestRevision)
+ details["time"] = res["time"]
self.updateOptionDict(details)
try:
--
1.8.0.276.gd9397fc
^ permalink raw reply related
* [PATCH 0/6] git p4 error handling
From: Pete Wyckoff @ 2012-11-23 22:35 UTC (permalink / raw)
To: git
These are assorted minor fixes. They should be safe for 1.8.1,
and are not urgent enough for maint.
Four of them deal with handling errors from p4d better. The first two
of these have been seen on the list already. The third showed up in my
own testing. The fourth adds a test to make sure that existing error
handling continues to work.
git p4: catch p4 describe errors
git p4: handle servers without move support
git p4: catch p4 errors when streaming file contents
git p4 test: display unresolvable host error
These two are small cleanups found by pylint, one of which is an
obvious (but rare) bug.
git p4: fix labelDetails typo in exception
git p4: remove unneeded cmd initialization
git-p4.py | 97 ++++++++++++++++++++++++++++++++++++++----------
t/t9800-git-p4-basic.sh | 25 ++++++++++++-
t/t9814-git-p4-rename.sh | 35 +++++++++++++++++
3 files changed, 137 insertions(+), 20 deletions(-)
--
1.8.0.276.gd9397fc
^ permalink raw reply
* [PATCH] diff: Fixes shortstat number of files
From: Antoine Pelisse @ 2012-11-23 21:27 UTC (permalink / raw)
To: git, gitster; +Cc: Antoine Pelisse
There is a discrepancy between the last line of `git diff --stat`
and `git diff --shortstat` in case of a merge.
The unmerged files are actually counted twice, thus doubling the
value of "file changed".
In fact, while stat decrements number of files when seeing an unmerged
file, shortstat doesn't.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
diff.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index e89a201..5c6bcbd 100644
--- a/diff.c
+++ b/diff.c
@@ -1704,9 +1704,8 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option
int added = data->files[i]->added;
int deleted= data->files[i]->deleted;
- if (data->files[i]->is_unmerged)
- continue;
- if (!data->files[i]->is_renamed && (added + deleted == 0)) {
+ if (data->files[i]->is_unmerged ||
+ (!data->files[i]->is_renamed && (added + deleted == 0))) {
total_files--;
} else if (!data->files[i]->is_binary) { /* don't count bytes */
adds += added;
--
1.7.9.5
^ permalink raw reply related
* Re: Requirements for integrating a new git subcommand
From: Christian Couder @ 2012-11-23 20:21 UTC (permalink / raw)
To: esr; +Cc: Shawn Pearce, git
In-Reply-To: <20121122221107.GA16069@thyrsus.com>
On Thu, Nov 22, 2012 at 11:11 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Shawn Pearce <spearce@spearce.org>:
>> [Lots of helpful stuff ended by]
>> > 4. How does "git help" work? That is, how is a subcommand expected
>> > to know when it is being called to export its help text?
>>
>> IIRC "git help foo" runs "man git-foo".
>
> OK, that makes sense.
"git help" can also launch a browser to display the HTML version of
the man page.
It is looking for man pages and HTML docs in the paths given by "git
--man-path" and "git --html-path".
Cheers,
Christian.
^ permalink raw reply
* Re: [PATCH v3] Completion must sort before using uniq
From: Felipe Contreras @ 2012-11-23 19:21 UTC (permalink / raw)
To: Marc Khouzam; +Cc: Junio C Hamano, git, SZEDER Gábor
In-Reply-To: <CAFj1UpH8h6c7xHuRG6F+pLy5YMvsJ0QdXsotCpLKnht0PsdiNw@mail.gmail.com>
On Fri, Nov 23, 2012 at 3:02 PM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> The user can be presented with invalid completion results
> when trying to complete a 'git checkout' command. This can happen
> when using a branch name prefix that matches multiple remote branches.
>
> For example, if available branches are:
> master
> remotes/GitHub/maint
> remotes/GitHub/master
> remotes/origin/maint
> remotes/origin/master
>
> When performing completion on 'git checkout ma' the user will be
> given the choices:
> maint
> master
>
> However, 'git checkout maint' will fail in this case, although
> completion previously said 'maint' was valid. Furthermore, when
> performing completion on 'git checkout mai', no choices will be
> suggested. So, the user is first told that the branch name
> 'maint' is valid, but when trying to complete 'mai' into 'maint',
> that completion is no longer valid.
>
> The completion results should never propose 'maint' as a valid
> branch name, since 'git checkout' will refuse it.
>
> The reason for this bug is that the uniq program only
> works with sorted input. The man page states
> "uniq prints the unique lines in a sorted file".
>
> When __git_refs uses the guess heuristic employed by checkout for
> tracking branches it wants to consider remote branches but only if
> the branch name is unique. To do that, it calls 'uniq -u'. However
> the input given to 'uniq -u' is not sorted.
>
> Therefore, in the above example, when dealing with 'git checkout ma',
> "__git_refs '' 1" will find the following list:
> master
> maint
> master
> maint
> master
>
> which, when passed to 'uniq -u' will remain the same. Therefore
> 'maint' will be wrongly suggested as a valid option.
>
> When dealing with 'git checkout mai', the list will be:
> maint
> maint
>
> which happens to be sorted and will be emptied by 'uniq -u',
> properly ignoring 'maint'.
>
> A solution for preventing the completion script from suggesting
> such invalid branch names is to first call 'sort' and then 'uniq -u'.
>
> Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
Looks good. Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com>
--
Felipe Contreras
^ permalink raw reply
* cherry-pick and reset while merging
From: Tobias Reuleaux @ 2012-11-23 19:00 UTC (permalink / raw)
To: git
Hello everyone,
we recently switched to git and so far it's doing a terriffic job.
Today though, we had a problem that we couldn't figure until now.
We have a master, a develop and a refactor branch. Today we merged
refactor into develop, which dramatically changes some source files. I
needed to change only one line in master and develop afterwards.
So i changed it in develop and cherry picked it into master.
$ git cherry-pick a165eb8c7b4306f349a9754102315195a17208ab
Got of course a conflict and also know that this was a bad idea. So i
decided to reset this to HEAD and do a checkout from my HEAD after.
$ git reset HEAD somefile
$ git checkout -- somefile
After that i modified my line by hand in the file (so the original
modification from develop wasn't there), made a diff afterwards (which
only showed the modification of the one line) and committed my changes.
$ git diff somefile
$ git push
In the end the new file from develop was pushed to master, which isn't
of course what i wanted.
What did i do wrong? Why does git reset to the develop HEAD during the
merge? Why is the checkout of the file a version of the file before the
cherry-picked commit? Why does my diff show only the one changed line?
A lot of questions i know. I'm totally new to git so can someone please
help me!
Thank you in advance!
kind regards,
Tobias
^ permalink raw reply
* Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: W. Trevor King @ 2012-11-23 17:54 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121123162329.GF2806@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 3742 bytes --]
On Fri, Nov 23, 2012 at 11:23:29AM -0500, W. Trevor King wrote:
> On Fri, Nov 23, 2012 at 04:55:21PM +0100, Heiko Voigt wrote:
> > On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:
> > > "W. Trevor King" <wking@tremily.us> writes:
> > >
> > > > The superproject gitlink should only be updated after
> > > >
> > > > $ git submodule update --pull
> > > >
> > > > A plain
> > > >
> > > > $ git submodule update
> > > >
> > > > would still checkout the previously-recorded SHA, not the new upstream
> > > > tip.
> > >
> > > Hrm, doesn't it make the "float at the tip of a branch" mode
> > > useless, though?
> >
> > How about having a branch config option and reusing our
> > submodule.$name.update option for specifying whether the user wants to
> > always float to the tip of the branch?
>
> I'm adding "update --pull" as one of the update options in v4, which I
> am writing up as we speak ;).
On second thought, this does not seem to be a good idea. The current
fancy update styles (--rebase, --merge) are both for cases where you
have local commits in the submodule and are trying to incorporate new
gitlinks from an updated superproject into the submodule's checked out
branch:
superproject $ cd submod
superproject $ git checkout next
submod $ …hack hack hack…
submod $ git commit …
submod $ cd ..
…upstream superproject changes…
superproject $ git pull
…updated SHA1 for submod gitlink…
superproject $ git submodule update --merge
…merge superproject's gitlink SHA1 into local submod branch…
My submodule.<name>.branch option gives a local branch to
check out:
…upstream submod changes…
superproject $ git cd ssubmodule update --pull
…fetch upstream submod changes and ff-merge into local submodule.<name>.branch…
This seems suitably distinct that bundling it with the other update
options will just add confusion.
So, let's rethink this approach. I'm trying to pull the upstream
version of my local submod branch. The difficulties with this are:
1. Checking out a local branch (from the default detached state)
to do something on it requires an ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && …'
2. The remote pulling behavior is configured in
.git/modules/<name>/config, which is not tracked in the repository
itself.
I'm ok with forcing local users to handle 2 manually (or implicitly),
but 1 is crazy. Addin submodule.<name>.branch explicitly to
.gitmodules is a step towards fixing 1, but submod pull doesn't match
an existing submodules-implemented workflow. Perhaps a better choice
would be to borrow the implicit-local-checkout behaviour used by
--rebase and --merge. We could add
$ git submodule update --branch
to checkout the gitlinked SHA1 as submodule.<name>.branch in each of
the submodules, leaving the submodules on the .gitmodules-configured
branch. Effectively (for each submodule):
$ git branch -f $branch $sha1
$ git checkout $branch
Then I could use
$ git submodule foreach 'git pull'
to update my submodule tracking branches (without further "git
submodule" restructuring).
This would help everyone that doesn't like the detached head state (me
and --rebase/--merge users). I could avoid implementing "update
--pull", and all of the difficulty in configuring upstream merge
choices (2) would be punted to the user making local edits in
.git/modules/<name>/config.
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: Sascha Cunz @ 2012-11-23 17:24 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, W. Trevor King, Git, Jeff King, Phil Hord,
Shawn Pearce, Jens Lehmann, Nahor
In-Reply-To: <20121123155521.GB14509@book.hvoigt.net>
Am Freitag, 23. November 2012, 16:55:21 schrieb Heiko Voigt:
> I am still a little bit undecided about an automatically crafted commit.
>
> At $dayjob we sometimes update submodules to their tip without any
> superproject changes just to make sure we use the newest version. Most
> of the time the commit messages are along the lines of "updated
> submodule x to master".
>
> On one hand Junio is right that the person updating to the newest
> submodule stuff has no clue what to write in this message.
I've been thinking about that for a while, when I started using submodules. In
the end, I concluded, that what I really want to see in the commit message, is
something similar to $(git shortlog $OLD_SHA1..$NEW_SHA1).
I've scripted that and taught my CI-Server to do it automatically, if
possible. So most of the time, I really don't want an "automatically crafted
commit" whenever something causes the tip of a submodule to be at a new SHA1.
Just my $.02, though.
Sascha
^ permalink raw reply
* [PATCH] gitk tag delete/rename support
From: Leon KUKOVEC @ 2012-11-23 16:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Leon KUKOVEC
In-Reply-To: <1353649899-15641-1-git-send-email-leon.kukovec@gmail.com>
Right clicking on a tag pops up a menu, which allows
tag to be renamed or deleted.
Signed-off-by: Leon KUKOVEC <leon.kukovec@gmail.com>
---
gitk-git/gitk | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 154 insertions(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..38cc233 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2032,6 +2032,7 @@ proc makewindow {} {
global have_tk85 use_ttk NS
global git_version
global worddiff
+ global tagctxmenu
# The "mc" arguments here are purely so that xgettext
# sees the following string as needing to be translated
@@ -2581,6 +2582,13 @@ proc makewindow {} {
{mc "Run git gui blame on this line" command {external_blame_diff}}
}
$diff_menu configure -tearoff 0
+
+ set tagctxmenu .tagctxmenu
+ makemenu $tagctxmenu {
+ {mc "Rename this tag" command mvtag}
+ {mc "Delete this tag" command rmtag}
+ }
+ $tagctxmenu configure -tearoff 0
}
# Windows sends all mouse wheel events to the current focused window, not
@@ -6400,6 +6408,7 @@ proc drawtags {id x xt y1} {
-font $font -tags [list tag.$id text]]
if {$ntags >= 0} {
$canv bind $t <1> [list showtag $tag_quoted 1]
+ $canv bind $t $ctxbut [list showtagmenu %X %Y $id $tag_quoted]
} elseif {$nheads >= 0} {
$canv bind $t $ctxbut [list headmenu %X %Y $id $tag_quoted]
}
@@ -8931,6 +8940,113 @@ proc domktag {} {
return 1
}
+proc mvtag {} {
+ global mvtagtop
+ global tagmenuid tagmenutag tagctxmenu maintag NS
+ global mvtagtag
+
+ set mvtagtag $tagmenutag
+ set top .movetag
+ set mvtagtop $top
+ catch {destroy $top}
+ ttk_toplevel $top
+ make_transient $top .
+
+ ${NS}::label $top.msg -text [mc "Enter a new tag name:"]
+ ${NS}::entry $top.tag -width 60 -textvariable mvtagtag
+
+ grid $top.msg -sticky w -row 0 -column 0
+ grid $top.tag -sticky w -row 0 -column 1
+
+ ${NS}::frame $top.buts
+ ${NS}::button $top.buts.gen -text [mc "Rename"] -command mvtaggo
+ ${NS}::button $top.buts.can -text [mc "Cancel"] -command mvtagcan
+ bind $top <Key-Return> mvtaggo
+ bind $top <Key-Escape> mvtagcan
+ grid $top.buts.gen $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
+}
+
+proc domvtag {} {
+ global mvtagtop env tagids idtags tagmenutag tagmenuid mvtagtag
+
+ set tag $mvtagtag
+ set id $tagmenuid
+
+ # add tag
+ # XXX: reuse domktag including keeping comment from the original tag.
+ if {[catch {
+ exec git tag $tag $id
+ } err]} {
+ error_popup "[mc "Error renaming tag:"] $err" $mvtagtop
+ return 0
+ }
+
+ # delete old tag, content stored in $tagmenutag and $tagmenuid
+ dormtag
+
+ set tagids($tag) $id
+ lappend idtags($id) $tag
+ redrawtags $id
+ addedtag $id
+ dispneartags 0
+ run refill_reflist
+ return 1
+}
+
+proc rmtag {} {
+ global rmtagtop
+ global tagmenuid tagmenutag tagctxmenu maintag NS
+
+ set top .maketag
+ set rmtagtop $top
+ catch {destroy $top}
+ ttk_toplevel $top
+ make_transient $top .
+ ${NS}::label $top.title -text [mc "Delete tag"]
+ grid $top.title - -pady 10
+
+ ${NS}::label $top.msg -text [mc "You are about to delete a tag"]
+ ${NS}::label $top.tagname -foreground Red -text [mc "$tagmenutag"]
+ grid $top.msg -sticky w -row 0 -column 0
+ grid $top.tagname -sticky w -row 0 -column 1
+
+ ${NS}::frame $top.buts
+ ${NS}::button $top.buts.gen -text [mc "Delete"] -command rmtaggo
+ ${NS}::button $top.buts.can -text [mc "Cancel"] -command rmtagcan
+ bind $top <Key-Return> rmtaggo
+ bind $top <Key-Escape> rmtagcan
+ grid $top.buts.gen $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
+}
+
+proc dormtag {} {
+ global rmtagtop env tagids idtags tagmenutag tagmenuid
+
+ set tag $tagmenutag
+ set id $tagmenuid
+
+ if {[catch {
+ exec git tag -d $tag
+ } err]} {
+ error_popup "[mc "Error deleting tag:"] $err" $rmtagtop
+ return 0
+ }
+
+ unset tagids($tag)
+ set idx [lsearch $idtags($id) $tag]
+ set idtags($id) [lreplace $idtags($id) $idx $idx]
+
+ redrawtags $id
+ dispneartags 0
+ run refill_reflist
+ return 1
+}
+
proc redrawtags {id} {
global canv linehtag idpos currentid curview cmitlisted markedid
global canvxmax iddrawn circleitem mainheadid circlecolors
@@ -8974,6 +9090,30 @@ proc mktaggo {} {
mktagcan
}
+proc rmtagcan {} {
+ global rmtagtop
+
+ catch {destroy $rmtagtop}
+ unset rmtagtop
+}
+
+proc rmtaggo {} {
+ if {![dormtag]} return
+ rmtagcan
+}
+
+proc mvtagcan {} {
+ global mvtagtop
+
+ catch {destroy $mvtagtop}
+ unset mvtagtop
+}
+
+proc mvtaggo {} {
+ if {![domvtag]} return
+ mvtagcan
+}
+
proc writecommit {} {
global rowmenuid wrcomtop commitinfo wrcomcmd NS
@@ -9288,6 +9428,20 @@ proc headmenu {x y id head} {
tk_popup $headctxmenu $x $y
}
+# context menu for a tag
+proc showtagmenu {x y id tag} {
+ global tagmenuid tagmenutag tagctxmenu maintag
+
+ stopfinding
+ set tagmenuid $id
+ set tagmenutag $tag
+ set state normal
+
+ $tagctxmenu entryconfigure 0 -state normal
+ $tagctxmenu entryconfigure 1 -state normal
+ tk_popup $tagctxmenu $x $y
+}
+
proc cobranch {} {
global headmenuid headmenuhead headids
global showlocalchanges
--
1.7.9.5
^ permalink raw reply related
* Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: W. Trevor King @ 2012-11-23 16:30 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121123162329.GF2806@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
On Fri, Nov 23, 2012 at 11:23:29AM -0500, W. Trevor King wrote:
> On Fri, Nov 23, 2012 at 05:03:01PM +0100, Heiko Voigt wrote:
> > There is an important question still unanswered here for me: How does
> > the submodule get the configuration what the local branch tracks on the
> > remote side?
>
> A good point ;). I'm actaully using submodule.<name>.branch to store
> the submodule's local branch name. The remote branch name for the
> pull is implicit, and defaults to something setup according to
> branch.autosetupmerge (I think). If you want to get more complicated
> than this, we'll probably have to add submodule.<name>.branch and
> submodule.<name>.remote sections to augment the
> submodule.<name>.branch setting. I'm not sure this is worth it.
These settings are currently stored in
.git/modules/<name>/config
What we're missing is a place to store them in the .gitmodules file.
I'll poke around in the module-config initialization and wait for
inspiration ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Requirements for integrating a new git subcommand
From: Eric S. Raymond @ 2012-11-23 16:29 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJsQjXEhmfRUEgBc=RkF3Lk8QVqUqmeAJiOZ0dtvcMYVFw@mail.gmail.com>
Shawn Pearce <spearce@spearce.org>:
> Nope, it just has to be executable. We don't have any current Python
> code. IIRC the last Python code was the implementation of
> git-merge-recursive, which was ported to C many years ago.
This turns out not to be quite true. The tree currently includes
two Python scripts, a Perforce importer and a test helper.
I'm in he process of writing up a document on command integration
based on your answers. I will submit it for incusion in the tree
shortly.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: W. Trevor King @ 2012-11-23 16:23 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121123155521.GB14509@book.hvoigt.net>
[-- Attachment #1: Type: text/plain, Size: 2806 bytes --]
On Fri, Nov 23, 2012 at 04:55:21PM +0100, Heiko Voigt wrote:
> On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:
> > "W. Trevor King" <wking@tremily.us> writes:
> >
> > > The superproject gitlink should only be updated after
> > >
> > > $ git submodule update --pull
> > >
> > > A plain
> > >
> > > $ git submodule update
> > >
> > > would still checkout the previously-recorded SHA, not the new upstream
> > > tip.
> >
> > Hrm, doesn't it make the "float at the tip of a branch" mode
> > useless, though?
>
> How about having a branch config option and reusing our
> submodule.$name.update option for specifying whether the user wants to
> always float to the tip of the branch?
I'm adding "update --pull" as one of the update options in v4, which I
am writing up as we speak ;).
> 1. If submodule.$name.update is pull it would checkout the specified tip.
and pull from the submodule's upstream. This doesn't need the
recorded $sha1, so I may have to rework the current
if (clear_local_git_env; cd "$sm_path" && $command "$sha1")
> 2. If submodule.$name.update is checkout or none it would do the usual
> thing and you need to specify --pull to get the tip.
Exactly.
> So currently I am more on the "have an automatically generated
> commit message" side. Its in a similar corner like merge commits, that
> are also generated, for me. We could have it as the default and a
> --no-commit option (like merge) for people that want to stage submodules
> individually.
This sounds reasonable, but I'd like to postpone message-generation
sugar until we get the basic functionality ironed out.
On Fri, Nov 23, 2012 at 05:03:01PM +0100, Heiko Voigt wrote:
> On Tue, Nov 20, 2012 at 07:19:12AM -0500, W. Trevor King wrote:
> > The benefit is that Ævar's
> >
> > $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
> >
> > becomes
> >
> > $ git submodule update --pull
>
> There is an important question still unanswered here for me: How does
> the submodule get the configuration what the local branch tracks on the
> remote side?
A good point ;). I'm actaully using submodule.<name>.branch to store
the submodule's local branch name. The remote branch name for the
pull is implicit, and defaults to something setup according to
branch.autosetupmerge (I think). If you want to get more complicated
than this, we'll probably have to add submodule.<name>.branch and
submodule.<name>.remote sections to augment the
submodule.<name>.branch setting. I'm not sure this is worth it.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: Heiko Voigt @ 2012-11-23 16:03 UTC (permalink / raw)
To: W. Trevor King
Cc: Junio C Hamano, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121120121912.GC7096@odin.tremily.us>
On Tue, Nov 20, 2012 at 07:19:12AM -0500, W. Trevor King wrote:
> The benefit is that Ævar's
>
> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
>
> becomes
>
> $ git submodule update --pull
There is an important question still unanswered here for me: How does
the submodule get the configuration what the local branch tracks on the
remote side?
Cheers Heiko
^ permalink raw reply
* Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: Heiko Voigt @ 2012-11-23 15:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: W. Trevor King, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <7vhaokrr01.fsf@alter.siamese.dyndns.org>
On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
>
> > The superproject gitlink should only be updated after
> >
> > $ git submodule update --pull
> >
> > A plain
> >
> > $ git submodule update
> >
> > would still checkout the previously-recorded SHA, not the new upstream
> > tip.
>
> Hrm, doesn't it make the "float at the tip of a branch" mode
> useless, though?
How about having a branch config option and reusing our
submodule.$name.update option for specifying whether the user wants to
always float to the tip of the branch?
1. If submodule.$name.update is pull it would checkout the specified tip.
2. If submodule.$name.update is checkout or none it would do the usual
thing and you need to specify --pull to get the tip.
I am still a little bit undecided about an automatically crafted commit.
At $dayjob we sometimes update submodules to their tip without any
superproject changes just to make sure we use the newest version. Most
of the time the commit messages are along the lines of "updated
submodule x to master".
On one hand Junio is right that the person updating to the newest
submodule stuff has no clue what to write in this message. On the other
hand someone might as well just use this functionality to get all the
tips of all the submodules checked out. He then individually decides
which changes to take by using add but will then still use a commit
message like the one above.
So currently I am more on the "have an automatically generated
commit message" side. Its in a similar corner like merge commits, that
are also generated, for me. We could have it as the default and a
--no-commit option (like merge) for people that want to stage submodules
individually.
Cheers Heiko
^ permalink raw reply
* Re: Requirements for integrating a new git subcommand
From: Eric S. Raymond @ 2012-11-23 15:53 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Shawn Pearce, git
In-Reply-To: <50AF3E36.4080800@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net>:
> Regarding git-weave, I'm wondering (without having looked at the code)
> how this relates to git-archiv and git-fast-import/export, i.e. how much
> this leverages existing infrastructure rather than reinventing the
> wheel. Do your "trees" correspond to a "git tree"?
The unravel operation of git-weave is something like running
git-archive on every revision and saving the results in
sequentially-named directories, except that it also produces a
metadata file that allows the operation to be inverted.
So it is strictly more powerful.
The weave operation could be implemented using git fast-import, which
I am quite intimately familiar with from having written reposurgeon.
Functionally, the difference is that it would be a PITA to patch a
fast-import stream to insert or modify or remove revisions in the
middle, because the content of any given revision is in blobs that can
stretch arbitrarily far back from its commit and are shared with
other revisions. With git-weave tree-sequences these operations
are easy and safe.
> Again, without having looked at the code, it seems to me that exploding
> blob and tree objects might give you a structure not much unlike
> weave's, and your instruction sheet resembles that of fast-import quite
> a bit (plus date fill-in etc.).
The weave log resembles an import stream, yes - that's because they
have to capture the same data ontology. One major difference is that weave
logs are designed to be generated and edited by humans.
> One could even dream about implementing this as a remote helper instead...
What is a "remote helper" in this context?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: git bash does not access drive f:
From: Angelo Borsotti @ 2012-11-23 15:48 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <20121123153106.GA14509@book.hvoigt.net>
Hi Heiko,
I have changed the external drive and seen that the new one works. The
issue is, I guess, that the first drive was named "My Passport", with
a space in it, while the second one is "Iomega". Spaces in drive names
are not accepted by Linux, which could explain why they are a problem
also with git bash (even if bash could access them using what is
passed to it, which is a drive letter, and not the drive name).
Thank you
-Angelo
On 23 November 2012 16:31, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> Hi,
>
> On Thu, Nov 22, 2012 at 08:07:55AM +0100, Angelo Borsotti wrote:
>> I have attached an external disc, which appears on Windows as drive f:
>> in Windows Explorer.
>> Right-clicking on it displays a context menu showing (among other
>> items) Git Init Here, Git Gui and
>> Git Bash. The first two work properly on that drive.
>> However, the git bash does not. Not even the one that is run from the icon:
>>
>> $ cd f:
>> sh.exe": cd: f:: No such file or directory
>>
>>
>> Is there any way to make it access drive f?
>
> Try using the environment variable MSYS_WATCH_FSTAB=YesPlease.
>
> We have an optimization in msys that does not update the virtually
> mounted folders and makes msys executable startups faster. I had similar
> issues with mounted disk images.
>
> The other alternative: After having the external disc mounted logout and
> login again that AFAIR that should also help.
>
> Cheers Heiko
^ permalink raw reply
* Re: Requirements for integrating a new git subcommand
From: Eric S. Raymond @ 2012-11-23 15:35 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.1211231022440.1431@ds9.cixit.se>
Peter Krefting <peter@softwolves.pp.se>:
> I was just about to say that the import direction of this seems to
> fill the same need as contrib/fast-import/import-directories.perl
> that I submitted a few years back.
Yours was the closest in functionality, yes.
> Your version seems only to be able to import a linear history,
> however, my tool does support creating merge commits (basically, the
> history I had to import was very messy and contained a lot of
> snapshot directories having been worked on in parallel).
git-weave can *weave* (import) a sequence with merge commits, as your
tool can. What it can't do is unravel a nonlinear repo into a tree
sequence that will round-trip through the weave operation. (Though I
thought of a way I might be able to fix that last night.)
> Anyway, my sentiment is that if you can add support for merges in
> you weave tool, then I am very much for removing my old script from
> the repository.
The support is there. I will take this as direction to (a) add a
test load demonstrating this, and (b) include the removal of
import-directories.perl in my integration patch.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: git bash does not access drive f:
From: Heiko Voigt @ 2012-11-23 15:31 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9Ae46PNRex9QrEy9gTgqAbn8KUFifmxQU4s5K5mDDmDZQ@mail.gmail.com>
Hi,
On Thu, Nov 22, 2012 at 08:07:55AM +0100, Angelo Borsotti wrote:
> I have attached an external disc, which appears on Windows as drive f:
> in Windows Explorer.
> Right-clicking on it displays a context menu showing (among other
> items) Git Init Here, Git Gui and
> Git Bash. The first two work properly on that drive.
> However, the git bash does not. Not even the one that is run from the icon:
>
> $ cd f:
> sh.exe": cd: f:: No such file or directory
>
>
> Is there any way to make it access drive f?
Try using the environment variable MSYS_WATCH_FSTAB=YesPlease.
We have an optimization in msys that does not update the virtually
mounted folders and makes msys executable startups faster. I had similar
issues with mounted disk images.
The other alternative: After having the external disc mounted logout and
login again that AFAIR that should also help.
Cheers Heiko
^ 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