Re: [PATCH] am: replace uses of --resolved with --continue
On Wed, Jun 26, 2013 at 11:06:41PM +0300, Kevin Bracey wrote:
git am was previously modified to provide --continue for consistency
with rebase, merge etc, and the documentation changed to showing
--continue as the primary form.
Complete the work by replacing remaining uses of --resolved by
--continue, most notably in suggested command reminders.
Signed-off-by: Kevin Bracey ke...@bracey.fi
---
Documentation/git-am.txt | 4 ++--
Documentation/user-manual.txt | 2 +-
git-am.sh | 8
t/t7512-status-help.sh| 4 ++--
wt-status.c | 2 +-
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 5bbe7b6..54d8461 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -132,7 +132,7 @@ default. You can use `--no-utf8` to override this.
--resolvemsg=msg::
When a patch failure occurs, msg will be printed
to the screen before exiting. This overrides the
- standard message informing you to use `--resolved`
+ standard message informing you to use `--continue`
or `--skip` to handle the failure. This is solely
for internal use between 'git rebase' and 'git am'.
@@ -176,7 +176,7 @@ aborts in the middle. You can recover from this in one
of two ways:
. hand resolve the conflict in the working directory, and update
the index file to bring it into a state that the patch should
- have produced. Then run the command with the '--resolved' option.
+ have produced. Then run the command with the '--continue' option.
It isn't new in this patch, but there is an inconsistency in the quoting
of the options here. In the previous hunk we use backticks but here it
uses SQs.
The documentation isn't at all consistent on this, but
backticks seem to be the preferred style (there are some false positives
in both counts but this gives a good indication):
$ git grep '-- -- Documentation/ | wc -l
186
$ git grep '`--' -- Documentation/ | wc -l
487
The command refuses to process new mailboxes until the current
operation is finished, so if you decide to start over from scratch,
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index e831cc2..8218cf9 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1835,7 +1835,7 @@ Once the index is updated with the results of the
conflict
resolution, instead of creating a new commit, just run
-
-$ git am --resolved
+$ git am --continue
-
and Git will create the commit for you and continue applying the
diff --git a/git-am.sh b/git-am.sh
index 9f44509..7ea40fe 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -6,7 +6,7 @@ SUBDIRECTORY_OK=Yes
OPTIONS_KEEPDASHDASH=
OPTIONS_SPEC=\
git am [options] [(mbox|Maildir)...]
-git am [options] (--resolved | --skip | --abort)
+git am [options] (--continue | --skip | --abort)
--
i,interactive run interactively
b,binary* (historical option -- no-op)
@@ -102,7 +102,7 @@ stop_here_user_resolve () {
printf '%s\n' $resolvemsg
stop_here $1
fi
-eval_gettextln When you have resolved this problem, run \\$cmdline
--resolved\.
+eval_gettextln When you have resolved this problem, run \\$cmdline
--continue\.
If you prefer to skip this patch, run \\$cmdline --skip\ instead.
To restore the original branch and stop patching, run \\$cmdline --abort\.
@@ -523,7 +523,7 @@ Use \git am --abort\ to remove it.)
esac
fi
- # Make sure we are not given --skip, --resolved, nor --abort
+ # Make sure we are not given --skip, --continue, nor --abort
test $skip$resolved$abort = ||
die $(gettext Resolve operation not in progress, we are not
resuming.)
@@ -670,7 +670,7 @@ do
# - patch is the patch body.
#
# When we are resuming, these files are either already prepared
- # by the user, or the user can tell us to do so by --resolved flag.
+ # by the user, or the user can tell us to do so by --continue flag.
case $resume in
'')
if test -f $dotest/rebasing
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index 4f09bec..bd8aab0 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -510,7 +510,7 @@ test_expect_success 'status in an am session: file
already exists' '
cat expected -\EOF
# On branch am_already_exists
# You are in the middle of an am session.
- # (fix conflicts and then run git am --resolved)
+ # (fix conflicts and then run git am --continue)
# (use git am --skip to skip this patch)
# (use git am --abort to restore the original branch)
#
@@ -532,7 +532,7 @@ test_expect_success 'status in an am session: file
[BUG] rebase should desambiguate abbreviated hashes before starting
I just ran into a funny edge-case when doing a long rebase: one of the rewritten commits got a sha1 starting with one of the abbreviated sha1's of a commit still to be applied. As a result, the rebase stopped with a funny-looking short SHA1 ... was ambiguous, which would not have occured if the shortened sha1's presented to the user were expanded to full sha1's before starting the rebase. -- Yann Dirson - Bertin Technologies -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] rebase should desambiguate abbreviated hashes before starting
On 27 June 2013 18:55, Yann Dirson dir...@bertin.fr wrote: I just ran into a funny edge-case when doing a long rebase: one of the rewritten commits got a sha1 starting with one of the abbreviated sha1's of a commit still to be applied. As a result, the rebase stopped with a funny-looking short SHA1 ... was ambiguous, which would not have occured if the shortened sha1's presented to the user were expanded to full sha1's before starting the rebase. I do many large rebases, and I have experienced this about a dozen times in the last few years. I'm not sure that rebase could predict the new hashes without actually creating the prior commits? So maybe the short SHA1 is too short? When the rebase stops with this message, my workaround is: The last (failed) entry is in .git/rebase-merge/done The next todo is the top entry in .git/rebase-merge/git-rebase-todo I enter the short SHA1 in gitk to find the long SHA1. I edit both the above files to move the failed entry back into the top of the todo file, with the long SHA1 And then git rebase --continue -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug on OS X...
I wanted to look at some OpenWRT bits this morning and ran into an issue cloning the packages repository when setting up the package feed. The feeds script executes this under the hood: git clone --depth 1 git://nbd.name/packages.git feeds/packages When trying to run the command directly on OS X, I see: :: git clone --depth 1 git://nbd.name/packages.git Cloning into 'packages'... remote: Counting objects: 4728, done. remote: Compressing objects: 100% (4013/4013), done. remote: Total 4728 (delta 158), reused 3339 (delta 94) Receiving objects: 100% (4728/4728), 3.85 MiB | 1.79 MiB/s, done. Resolving deltas: 100% (158/158), done. error: unable to find 9f041557a0c81f696280bb934731786e3d009b36 fatal: object of unexpected type fatal: index-pack failed I tried on Linux, and it succeeded. I tested with both 1.8.2 and 1.8.3.1. Unfortunately, I don't have time to dig through what's wrong at the moment so I thought I'd put it out there for others. Thanks! -John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] rebase should desambiguate abbreviated hashes before starting
David bouncingc...@gmail.com writes: I'm not sure that rebase could predict the new hashes without actually creating the prior commits? So maybe the short SHA1 is too short? It's OK to show the short sha1 to the user, but git rebase could and should expand these to complete sha1 right after the editor is closed. I think that's what Yann means. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] rebase should desambiguate abbreviated hashes before starting
On 27 June 2013 21:04, Matthieu Moy matthieu@grenoble-inp.fr wrote: David bouncingc...@gmail.com writes: I'm not sure that rebase could predict the new hashes without actually creating the prior commits? So maybe the short SHA1 is too short? It's OK to show the short sha1 to the user, but git rebase could and should expand these to complete sha1 right after the editor is closed. I think that's what Yann means. Yes. I realised that just after clicking send. Thanks :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Off-line deverloper workflow?
Hi, I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? Thanks in advance. -woody -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Do not call built-in aliases from scripts
Call built-in commands via the main executable (non-dashed form) without
relying on the aliases (dashed form) to be present. On some platforms,
e.g. those that do not properly support file system links, it is
inconvenient to ship the built-in aliases, so do not depend on their
presence.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
git-am.sh| 6 ++---
git-archimport.perl | 68
git-cvsexportcommit.perl | 18 ++---
git-cvsserver.perl | 50 +--
git-merge-octopus.sh | 2 +-
git-merge-one-file.sh| 8 +++---
git-merge-resolve.sh | 2 +-
git-parse-remote.sh | 2 +-
git-pull.sh | 2 +-
git-stash.sh | 2 +-
git-submodule.sh | 8 +++---
11 files changed, 84 insertions(+), 84 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 9f44509..ad67194 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,8 +16,8 @@ s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
keep-non-patch pass -b flag to git-mailinfo
-keep-cr pass --keep-cr flag to git-mailsplit for mbox format
-no-keep-cr do not pass --keep-cr flag to git-mailsplit
independent of am.keepcr
+keep-cr pass --keep-cr flag to git mailsplit for mbox format
+no-keep-cr do not pass --keep-cr flag to git mailsplit
independent of am.keepcr
c,scissors strip everything before a scissors line
whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
@@ -174,7 +174,7 @@ It does not apply to blobs recorded in its index.)
then
GIT_MERGE_VERBOSITY=0 export GIT_MERGE_VERBOSITY
fi
-git-merge-recursive $orig_tree -- HEAD $his_tree || {
+git merge-recursive $orig_tree -- HEAD $his_tree || {
git rerere $allow_rerere_autoupdate
die $(gettext Failed to merge in the changes.)
}
diff --git a/git-archimport.perl b/git-archimport.perl
index 9cb123a..ed2c741 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -343,10 +343,10 @@ sub process_patchset_accurate {
# switch to that branch if we're not already in that branch:
if (-e $git_dir/refs/heads/$ps-{branch}) {
- system('git-checkout','-f',$ps-{branch}) == 0 or die $! $?\n;
+ system('git','checkout','-f',$ps-{branch}) == 0 or die $! $?\n;
# remove any old stuff that got leftover:
- my $rm = safe_pipe_capture('git-ls-files','--others','-z');
+ my $rm = safe_pipe_capture('git','ls-files','--others','-z');
rmtree(split(/\0/,$rm)) if $rm;
}
@@ -367,7 +367,7 @@ sub process_patchset_accurate {
# find where we are supposed to branch from
if (! -e $git_dir/refs/heads/$ps-{branch}) {
- system('git-branch',$ps-{branch},$branchpoint) == 0 or die $!
$?\n;
+ system('git','branch',$ps-{branch},$branchpoint) == 0 or die
$! $?\n;
# We trust Arch with the fact that this is just a tag,
# and it does not affect the state of the tree, so
@@ -378,10 +378,10 @@ sub process_patchset_accurate {
ptag($ps-{id}, $branchpoint);
print * Tagged $ps-{id} at $branchpoint\n;
}
- system('git-checkout','-f',$ps-{branch}) == 0 or die $! $?\n;
+ system('git','checkout','-f',$ps-{branch}) == 0 or die $! $?\n;
# remove any old stuff that got leftover:
-my $rm = safe_pipe_capture('git-ls-files','--others','-z');
+my $rm = safe_pipe_capture('git','ls-files','--others','-z');
rmtree(split(/\0/,$rm)) if $rm;
return 0;
} else {
@@ -392,10 +392,10 @@ sub process_patchset_accurate {
}
# update the index with all the changes we got
-system('git-diff-files --name-only -z | '.
-'git-update-index --remove -z --stdin') == 0 or die $! $?\n;
-system('git-ls-files --others -z | '.
-'git-update-index --add -z --stdin') == 0 or die $! $?\n;
+system('git diff-files --name-only -z | '.
+'git update-index --remove -z --stdin') == 0 or die $! $?\n;
+system('git ls-files --others -z | '.
+'git update-index --add -z --stdin') == 0 or die $! $?\n;
return 1;
}
@@ -413,7 +413,7 @@ sub process_patchset_fast {
unless ($import) { # skip for import
if ( -e $git_dir/refs/heads/$ps-{branch}) {
# we know about this branch
-system('git-checkout',$ps-{branch});
+system('git','checkout',$ps-{branch});
} else {
# new branch! we need to verify a few things
die Branch on a non-tag! unless $ps-{type} eq 't';
@@ -423,7 +423,7 @@ sub process_patchset_fast {
# find where we are supposed to branch from
if (! -e
Re: Off-line deverloper workflow?
On Thu, Jun 27, 2013 at 08:46:56PM +0800, Woody Wu wrote: Hi, I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? There's a number of ways that git can communicate with an other git repo. However, communication needs access. You can for example e-mail changes or sen them as files manually with git sneakernet functionality. However those cases would be as bad (or worse) than to open your firewall. The best solution would be a remote repository outside your firewall where your inhouse team and your outhouse developer can share stuff with eachother. However the securitry for this special project will be lower. (Maybe this isn't an important project to you, I don't know). This repository can be at your inhouse-site, at your developer or at some third part. Use ssh with keys and passphrases to communicate. Keep in mind that a git repository contains all of your source history. Your security for that source code will be whatever security your outhouse developer has. If he fails with his security, there's no meaning with having great inhouse security. If this isn't an option I would suggest that you establish an encrypted sneakernet (for example over UPS/bike messengers/whatever) between your developer and your office. Or just ask yourself if your security settings really is sane. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: device files should be handled by git
On Wed, Jun 26, 2013 at 08:27:56PM -0700, Perry Wagle wrote: Hi -- I have a disk image of a small embedded device whose root file system I'd like to check-in to git as a means of distributing its GPL'd software. In that disk image are device files, which GIT studiously ignores. If symlinks are handled (contents being the path that the symlink points at), I don't see why device files can't be handled (contents being the type (char or block) and the major and minor device number). TAR, for example, handles this fine, except that using tar in git sort-of goes against the granularity of the objects being modified (like adding a bunch of extra sd?? devices), such that you are modifying a whole tar ball instead of the individual (device) files. Is there a reason not to handle device files other than its not traditional? That's the only reason given in google or the IRC channel. Thanks! In linux you can't create device files if your not root. On windows those files won't even exists (afaik). Wouldn't this be very unportable and hard to use (meaning that you need to handle your git repo as root or give git setuid root)? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Off-line deverloper workflow?
On Thu, Jun 27, 2013 at 2:46 PM, Woody Wu narkewo...@gmail.com wrote: I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? If he can set up an SSH server on his machine (outside the company network), then he can set up a mirror repo on his machine, where you can push changes from the office to him, and pull changes from him back into the office. Of course, you will probably need to synchronize this with him, especially if he's travelling and frequently offline or changing IP addresses. Also you need to be able to make outbound SSH connections through the company firewall, but AFAICS that is usually allowed. His work repo is then a local clone of the mirror repo, and when he's ready to publish some work to you, he pushes it to the mirror repo, and asks you to pull from the mirror repo. If the source code is not secret, you could even synchronize through GitHub or some other repo hosting service, which would be even easier to set up. Hope this helps, ...Johan Thanks in advance. -woody -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: device files should be handled by git
On Thu, Jun 27, 2013 at 3:08 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Wed, Jun 26, 2013 at 08:27:56PM -0700, Perry Wagle wrote: Is there a reason not to handle device files other than its not traditional? That's the only reason given in google or the IRC channel. In linux you can't create device files if your not root. On windows those files won't even exists (afaik). Wouldn't this be very unportable and hard to use (meaning that you need to handle your git repo as root or give git setuid root)? Device files will probably never be supported by Git for the reasons mentioned by Fredrik. If anything, etckeeper (http://joeyh.name/code/etckeeper/) would be a much more appropriate place to support this, although I don't think it currently does. Alternatively, you could follow the suggestions of http://superuser.com/questions/440873/git-unable-add-device-file (and elsewhere), and write a script for generating the device files, rather than storing them as-is. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Off-line deverloper workflow?
On Thu, Jun 27, 2013 at 08:06:05AM -0500, Tim Chase wrote: On 2013-06-27 20:46, Woody Wu wrote: I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? It would help to know a little more about the information flow and the starting conditions. - Was a clone of code made before leaving your office or does your colleague need to obtain the initial copy too? Yes, he had a clone already. - How securely do you need to transfer matters? (email? shared external service like Dropbox/Box.com/etc) I prefer email. - How frequently do updates need to be made? Maybe once several days. - In which direction do commits flow? Just from your colleague back to the office, or are there other updates happening in the office that your colleague needs to pull down to keep in sync? Bi-direction, means my colleague and my in-house team need to modify the code. Without such answers, it's a little hard to suggest more than transmitting either patch files or bundles using any of the following: email, a shared cloud drive, a shared host out accessible on the net, or sneakernet media (flash-drive or CD/DVD, perhaps via the postal system), or possibly other means. You may want to read more at git help format-patch git help am git help bundle -tkc -- I can't go back to yesterday - because I was a different person then -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Off-line deverloper workflow?
On Thu, Jun 27, 2013 at 03:14:05PM +0200, Johan Herland wrote: On Thu, Jun 27, 2013 at 2:46 PM, Woody Wu narkewo...@gmail.com wrote: I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? If he can set up an SSH server on his machine (outside the company network), then he can set up a mirror repo on his machine, where you can push changes from the office to him, and pull changes from him back into the office. Of course, you will probably need to synchronize this with him, especially if he's travelling and frequently offline or changing IP addresses. Also you need to be able to make outbound SSH connections through the company firewall, but AFAICS that is usually allowed. Outbound ssh to me is not a problem, but inbound ssh to him may be a big problem. You know hotel firewall or some home ADSL don't allow that. His work repo is then a local clone of the mirror repo, and when he's ready to publish some work to you, he pushes it to the mirror repo, and asks you to pull from the mirror repo. If the source code is not secret, you could even synchronize through GitHub or some other repo hosting service, which would be even easier to set up. Hope this helps, ...Johan Thanks in advance. -woody -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Johan Herland, jo...@herland.net www.herland.net -- I can't go back to yesterday - because I was a different person then -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Off-line deverloper workflow?
On Thu, Jun 27, 2013 at 3:41 PM, Woody Wu narkewo...@gmail.com wrote: On Thu, Jun 27, 2013 at 03:14:05PM +0200, Johan Herland wrote: On Thu, Jun 27, 2013 at 2:46 PM, Woody Wu narkewo...@gmail.com wrote: I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? If he can set up an SSH server on his machine (outside the company network), then he can set up a mirror repo on his machine, where you can push changes from the office to him, and pull changes from him back into the office. Of course, you will probably need to synchronize this with him, especially if he's travelling and frequently offline or changing IP addresses. Also you need to be able to make outbound SSH connections through the company firewall, but AFAICS that is usually allowed. Outbound ssh to me is not a problem, but inbound ssh to him may be a big problem. You know hotel firewall or some home ADSL don't allow that. In that case, you will need either: A) A third machine, accessible from both you and him (preferably over SSH), where you can store the repo. I don't know what your company infrastructure looks like, but maybe it's possible to setup a server in the DMZ outside your company firewall? B) Use a more manual mechanism like emailing bundles (as explained by Jean-Noël). ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Off-line deverloper workflow?
On Thu, Jun 27, 2013 at 03:43:51PM +0200, Jean-No?l Avila wrote: Le 27/06/2013 14:46, Woody Wu a écrit : Hi, I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? Thanks in advance. -woody -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html For a short time, I had the same issue. We came up using git bundle to bundle changes and exchange them via email. The setup was to work in two separate branches. The roaming developper started a new branch when leaving. After some work, she sent the commits on her branch as a bundle file. The origin merged the branch extracted from the developper's bundle and sent back the bundle of the changes on origin since the last merge. No doubt that both side need to understand well the workflow of fetch/merge. Bundle files can be encrypted for better security. Hope this helps. Many thanks, this method sounds suitable to me. I will go the learn anything about 'bundle'. Have a nice day! JN -- I can't go back to yesterday - because I was a different person then -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Off-line deverloper workflow?
On 2013-06-27 20:46, Woody Wu wrote: I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? It would help to know a little more about the information flow and the starting conditions. - Was a clone of code made before leaving your office or does your colleague need to obtain the initial copy too? - How securely do you need to transfer matters? (email? shared external service like Dropbox/Box.com/etc) - How frequently do updates need to be made? - In which direction do commits flow? Just from your colleague back to the office, or are there other updates happening in the office that your colleague needs to pull down to keep in sync? Without such answers, it's a little hard to suggest more than transmitting either patch files or bundles using any of the following: email, a shared cloud drive, a shared host out accessible on the net, or sneakernet media (flash-drive or CD/DVD, perhaps via the postal system), or possibly other means. You may want to read more at git help format-patch git help am git help bundle -tkc -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Off-line deverloper workflow?
Le 27/06/2013 14:46, Woody Wu a écrit : Hi, I have a colleague who has to left our office for three month, but still need to work on the project which is hosted on our in-office git repository. Problem is that our company has firewall, it's not possible or not allowed to access the company LAN outside the building. So I want to ask you expert, can you suggest a best practice of git workflow that suitable to my situation? Thanks in advance. -woody -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html For a short time, I had the same issue. We came up using git bundle to bundle changes and exchange them via email. The setup was to work in two separate branches. The roaming developper started a new branch when leaving. After some work, she sent the commits on her branch as a bundle file. The origin merged the branch extracted from the developper's bundle and sent back the bundle of the changes on origin since the last merge. No doubt that both side need to understand well the workflow of fetch/merge. Bundle files can be encrypted for better security. Hope this helps. JN -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions
On 2013-06-26 23.54, Ramsay Jones wrote: Torsten Bögershausen wrote: On 2013-06-25 23.18, Junio C Hamano wrote: Johannes Sixt j...@kdbg.org writes: Some context: This is about a patch by Ramsay that removes the schizophrenic lstat hack for Cygwin. Junio, can you please queue that patch in pu? Sure. Thanks. First of all, thanks for the work. Here some benchmark results, (The test run of the test suite did the same amout of time). The test suite runs noticeably faster for me. But: git status -uno in real life takes double the time, git 1.8.3 compared against pu with the vanilla l/stat 1 second - 2 seconds on linux kernel 0.2 seconds - 0.4 seconds on git.git Hmm, OK, I guess I will have to try something else. Sigh :( Do we have any known problems with the current implementation ? Yes. The next branch is currently broken. (see reply to Junio) Does speed matter ? One vote to keep the special cygwin functions. (And have a look how to improve the core.filemode) I don't understand this (parenthetical) comment; could you elaborate on this. ATB, Ramsay Jones This is probably wrong information: I had in mind that cygwin sets core.filemode=false, which is quite annoying when exchanging .sh files with linux. But that seems to be wrong, a quick test shows that core.filemode=true. Sorry for confusion. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/5] git-remote-mediawiki: Add preview subcommand into git mw.
Matthieu Moy matthieu@grenoble-inp.fr writes: benoit.per...@ensimag.fr writes: +do you want ? Use the -r option to specify the remote. Not that it really matters, but there should be no space before ? in English (although there is in French). (Shouldn't prevent merging) Other than that, the series looks good to me. Good work splitting patches 1 to 4, the history looks much nicer now. Thanks; queued. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
contrib/mw-to-git/Git/Mediawiki.pm
I just discovered a major problem for Mac OS and Windows people: In contrib/mw-to-git/ there is a file called git. And there is a directory called Git. This does not work very well on case insensitive file systems. When the file git is created, we can not create a directory called Git, as Git is mapped to git. And vice versa. Can we try to rename one of them ? The other interesting thing is that git 1.8.3 didn't like the situation: After checking out the pu branch, git status says: deleted:contrib/mw-to-git/Git/Mediawiki.pm So I could not change to another branch/commit... git stash didn't resolve the situation either. The following saved my repo: git mv contrib/mw-to-git/git contrib/mw-to-git/git.exe git checkout contrib/mw-to-git/Git/Mediawiki.pm git checkout -b xxx_git_Git_conflict git commit -a -m xxx_git_Git_conflict /Torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not call built-in aliases from scripts
Sebastian Schuberth sschube...@gmail.com writes:
Call built-in commands via the main executable (non-dashed form) without
relying on the aliases (dashed form) to be present. On some platforms,
e.g. those that do not properly support file system links, it is
inconvenient to ship the built-in aliases, so do not depend on their
presence.
In principle I have no problem with this change, if nothing other
than for consistency reasons. We tell users to write git foo, and
we tell users to say PATH=$(git --exec-path):$PATH if they want to
write git-foo, but we do tell them we prefer 'git foo' form. We
should do so ourselves where it is reasonable.
I vaguely recall that some people may have argued that git-foo is
one less exec(2) when we left these in our scripted Porcelains,
though, so on a platform with poorly performing fork/exec, this
change may be seen as detrimental. I do not know it matters that
much.
Having said all that, I do have a huge issue with the justification
in the proposed log message. If your plan is to make this:
$(git --exec-path)/git-ls-files
not to work with your port of Git, that implementation is _broken_
and is not a Git anymore.
Git can evolve over time, and if that is really your plan, the first
step you have to take is to revive the old discussion we had after
v1.6.0:
http://thread.gmane.org/gmane.comp.version-control.git/93511/focus=93825
and see if it is now a good idea. It could be in year 2014. It was
not in 2008.
I cannot apply this exact patch for an obvious and unrelated reason;
it seems to have changes, e.g. git am option help, that do not
have anything to do with the topic.
For a future reroll of this patch with only git-foo - 'git foo',
I would appreciate an independent review by at least one set of
eyes. It is very easy to blindly do this conversion with sed/perl
and fail to spot misconversion before sending it out.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
git-am.sh| 6 ++---
git-archimport.perl | 68
git-cvsexportcommit.perl | 18 ++---
git-cvsserver.perl | 50 +--
git-merge-octopus.sh | 2 +-
git-merge-one-file.sh| 8 +++---
git-merge-resolve.sh | 2 +-
git-parse-remote.sh | 2 +-
git-pull.sh | 2 +-
git-stash.sh | 2 +-
git-submodule.sh | 8 +++---
11 files changed, 84 insertions(+), 84 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 9f44509..ad67194 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,8 +16,8 @@ s,signoff add a Signed-off-by line to the commit
message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
keep-non-patch pass -b flag to git-mailinfo
-keep-cr pass --keep-cr flag to git-mailsplit for mbox format
-no-keep-cr do not pass --keep-cr flag to git-mailsplit
independent of am.keepcr
+keep-cr pass --keep-cr flag to git mailsplit for mbox format
+no-keep-cr do not pass --keep-cr flag to git mailsplit
independent of am.keepcr
c,scissors strip everything before a scissors line
whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
@@ -174,7 +174,7 @@ It does not apply to blobs recorded in its index.)
then
GIT_MERGE_VERBOSITY=0 export GIT_MERGE_VERBOSITY
fi
-git-merge-recursive $orig_tree -- HEAD $his_tree || {
+git merge-recursive $orig_tree -- HEAD $his_tree || {
git rerere $allow_rerere_autoupdate
die $(gettext Failed to merge in the changes.)
}
diff --git a/git-archimport.perl b/git-archimport.perl
index 9cb123a..ed2c741 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -343,10 +343,10 @@ sub process_patchset_accurate {
# switch to that branch if we're not already in that branch:
if (-e $git_dir/refs/heads/$ps-{branch}) {
- system('git-checkout','-f',$ps-{branch}) == 0 or die $! $?\n;
+ system('git','checkout','-f',$ps-{branch}) == 0 or die $! $?\n;
# remove any old stuff that got leftover:
- my $rm = safe_pipe_capture('git-ls-files','--others','-z');
+ my $rm = safe_pipe_capture('git','ls-files','--others','-z');
rmtree(split(/\0/,$rm)) if $rm;
}
@@ -367,7 +367,7 @@ sub process_patchset_accurate {
# find where we are supposed to branch from
if (! -e $git_dir/refs/heads/$ps-{branch}) {
- system('git-branch',$ps-{branch},$branchpoint) == 0 or die $!
$?\n;
+ system('git','branch',$ps-{branch},$branchpoint) == 0 or die
$! $?\n;
# We trust Arch with the fact that this is just a tag,
# and it does not affect the state of the tree, so
@@ -378,10 +378,10 @@ sub process_patchset_accurate {
ptag($ps-{id}, $branchpoint);
print *
Re: [PATCH 09/16] documentation: add documentation for the bitmap format
On Wed, Jun 26, 2013 at 7:45 PM, Jeff King p...@peff.net wrote: In particular, it seems like the slowness we saw with the v1 bitmap format is not what Shawn and Colby have experienced. So it's possible that our test setup is bad or different. Or maybe the C v1 reading implementation had some problems that are fixable. It's hard to say because we haven't shown any code that can be timed and compared. Right, the format and implementation in JGit can do Counting objects in 87ms for the Linux kernel history. But I think we are comparing apples to steaks here, Vincent is (rightfully) concerned about process startup performance, whereas our timings were assuming the process was already running. It would help everyone to understand the issues involved if we are at least looking at the same file format. And the pack-order versus idx-order for the bitmaps is still up in the air. Do we have numbers on the on-disk sizes of the resulting EWAHs? I did not see any presented in this thread, and I am very interested in this aspect of the series. The path hash cache should be taking about 9.9M of disk space, but I recall reading the bitmap file is 8M. I don't understand. Colby and I were very concerned about the size of the EWAH compressed bitmaps because we wanted hundreds of them for a large history like the kernel, and we wanted to minimize the amount of memory consumed by the bitmap index when loaded into the process. In the JGit implementation our copy of Linus' tree has 3.1M objects, an 81.5 MiB idx file, and a 3.8 MiB bitmap file. We were trying to keep the overhead below 10% of the idx file, and I think we have succeeded on that. With 3.1M objects the v2 bitmap proposed in this thread needs at least 11.8M, or 14+% overhead just for the path hash cache. The path hash cache may still be required, Colby and I have been debating the merits of having the data available for delta compression vs. the increase in memory required to hold it. The pack-order ones should be more amenable to run-length encoding, especially as you get further down into history (the tip ones would mostly be 1's, no matter how you order them). This is also true for the type bitmaps, but especially so in the JGit file ordering where we always write all trees before any blobs. The type bitmaps are very compact and basically amount to defining a single range in the file. This takes only a few words in the EWAH compressed format. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] am: replace uses of --resolved with --continue
John Keeping j...@keeping.me.uk writes: @@ -176,7 +176,7 @@ aborts in the middle. You can recover from this in one of two ways: . hand resolve the conflict in the working directory, and update the index file to bring it into a state that the patch should - have produced. Then run the command with the '--resolved' option. + have produced. Then run the command with the '--continue' option. It isn't new in this patch, but there is an inconsistency in the quoting of the options here. In the previous hunk we use backticks but here it uses SQs. Whatever the user is expected to literally type, like the dashed options, should be typeset in tt so `--continue` is the right form. I am not inviting anybody to throw a patch that was generated by blindly running: sed -e s/'\(--[a-z_]*\)'/`\1`/g to touch 50+ files without thinking, by the way. It is so easy that it can even be done by a trained monkey, but it also is very easy to fail to spot misconversion. Done in small batches with a throttled rate of patchflow, we may have sufficient review bandwidth to audit them. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: contrib/mw-to-git/Git/Mediawiki.pm
Benoît Person benoit.per...@ensimag.fr writes: Junio, Matthieu : should I resend a new version of my serie which renames the 'git' (lowercase) file into something like 'git-dev' ? I'd call it bin-wrapper/git, so that people can put bin-wrapper/ in their $PATH if needed, and by analogy with ../../bin-wrapper. If you go this way, don't forget to update the $0 relative paths. git-dev is OK with me too. (some comments directly mentionning the 'git' (lowercase) file needs to be updated as well in the Makefile) Yes. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not call built-in aliases from scripts
On Thu, Jun 27, 2013 at 6:11 PM, Junio C Hamano gits...@pobox.com wrote: Call built-in commands via the main executable (non-dashed form) without relying on the aliases (dashed form) to be present. On some platforms, e.g. those that do not properly support file system links, it is inconvenient to ship the built-in aliases, so do not depend on their presence. In principle I have no problem with this change, if nothing other than for consistency reasons. We tell users to write git foo, and we tell users to say PATH=$(git --exec-path):$PATH if they want to write git-foo, but we do tell them we prefer 'git foo' form. We should do so ourselves where it is reasonable. Consistency was indeed one of my intentions, though maybe not the primary one. I vaguely recall that some people may have argued that git-foo is one less exec(2) when we left these in our scripted Porcelains, though, so on a platform with poorly performing fork/exec, this change may be seen as detrimental. I do not know it matters that much. But isn't this only true for commands that are not built-ins? I.e., I can see how calling git-pull from a script is more efficient than calling git pull from the same script, because git pull would first execute git which in turn would spawn a shell to run the git-pull script. But calling e.g. git-merge and git merge should use almost the same code path in the git executable and not fork/exec at all because the merge command is built in, right? Having said all that, I do have a huge issue with the justification in the proposed log message. If your plan is to make this: $(git --exec-path)/git-ls-files not to work with your port of Git, that implementation is _broken_ and is not a Git anymore. I would at least like to have that option, yes, well knowing that such a port would not be considered to be a Git anymore. A typical use-case would be a portable Git for Windows, which is surprisingly popular. Such a portable version usually just ships as an archive without any kind of installer. The ZIP archive format on Windows does not support storing any kind of file system links, which means all executables for built-ins would need to be added as copies to the archive. While that does not add much to the archive size because all such files are equal to git.exe and thus compress well, the big surprise comes when extracting that archive as all the copies of git.exe make such a portable installation unnecessary big. On Windows, git.exe is about 1,34 MiB in size, which sums up to about 146 MiB of extra storage required if you have copies for all the built-ins instead of file system links. Git can evolve over time, and if that is really your plan, the first step you have to take is to revive the old discussion we had after v1.6.0: http://thread.gmane.org/gmane.comp.version-control.git/93511/focus=93825 and see if it is now a good idea. It could be in year 2014. It was not in 2008. Can I get around that discussion by adjusting the reasoning for the patch to mention consistency? I cannot apply this exact patch for an obvious and unrelated reason; it seems to have changes, e.g. git am option help, that do not have anything to do with the topic. Well, if the topic was consistency the changes would be related, or? As you were saying yourself, we tell users to prefer the git foo form, so we should also do so in the git am option help, IMHO. For a future reroll of this patch with only git-foo - 'git foo', I would appreciate an independent review by at least one set of eyes. It is very easy to blindly do this conversion with sed/perl and fail to spot misconversion before sending it out. At least the test suite (running on Linux) did not throw any failures at me after applying this patch. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: contrib/mw-to-git/Git/Mediawiki.pm
Oops, so sorry :/ It's defintely doable since the lowercase 'git' is only a bin-wrapper for git to ease development in contrib/mw-to-git/ . Junio, Matthieu : should I resend a new version of my serie which renames the 'git' (lowercase) file into something like 'git-dev' ? (some comments directly mentionning the 'git' (lowercase) file needs to be updated as well in the Makefile) Benoit -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] rebase should desambiguate abbreviated hashes before starting
Matthieu Moy matthieu@grenoble-inp.fr writes:
David bouncingc...@gmail.com writes:
I'm not sure that rebase could predict the new hashes without actually
creating
the prior commits? So maybe the short SHA1 is too short?
It's OK to show the short sha1 to the user, but git rebase could and
should expand these to complete sha1 right after the editor is closed. I
think that's what Yann means.
Yes, any short is by definition too short. I agree that it is
OK to show short one in rebase -i instruction sheet, as they are
uniquely generated before the actual replaying of commits begins,
and it is a sensible thing to do to convert them to the full form
before starting to do the real work.
It could be something as simple like this (not tested).
git-rebase--interactive.sh | 19 +++
1 file changed, 19 insertions(+)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f953d8d..6766b44 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -678,6 +678,23 @@ skip_unnecessary_picks () {
die Could not skip unnecessary pick commands
}
+# expand shortened commit object name to the full form
+expand_todo_commit_names () {
+ while read -r command rest
+ do
+ case $command in
+ '#'*)
+ ;;
+ *)
+ sha1=$(git rev-parse --verify --quiet ${rest%% *})
+ rest=$sha1 ${rest#* }
+ ;;
+ esac
+ printf '%s\n' $command${rest:+ }$rest
+ done $todo $todo.new
+ mv -f $todo.new $todo
+}
+
# Rearrange the todo list that has both pick sha1 msg and
# pick sha1 fixup!/squash! msg appears in it so that the latter
# comes immediately after the former, and change pick to
@@ -979,6 +996,8 @@ git_sequence_editor $todo ||
has_action $todo ||
die_abort Nothing to do
+expand_todo_commit_names
+
test -d $rewritten || test -n $force_rebase || skip_unnecessary_picks
output git checkout $onto || die_abort could not detach HEAD
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] rebase should desambiguate abbreviated hashes before starting
Junio C Hamano gits...@pobox.com writes:
It could be something as simple like this (not tested).
git-rebase--interactive.sh | 19 +++
1 file changed, 19 insertions(+)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f953d8d..6766b44 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -678,6 +678,23 @@ skip_unnecessary_picks () {
die Could not skip unnecessary pick commands
}
+# expand shortened commit object name to the full form
+expand_todo_commit_names () {
+ while read -r command rest
+ do
+ case $command in
+ '#'*)
+ ;;
+ *)
+ sha1=$(git rev-parse --verify --quiet ${rest%% *})
+ rest=$sha1 ${rest#* }
+ ;;
In case somebody wants to polish it to a real patch, this part
should at least be:
case $command in
'#'* | exec)
# Be careful for oddball commands like 'exec'
# that do not have a short-SHA-1 at the beginning
# of $rest.
;;
*)
sha1=$(git rev-parse --verify --quiet ${rest%% *})
rest=$sha1 ${rest#* }
;;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/16] documentation: add documentation for the bitmap format
On Thu, Jun 27, 2013 at 09:07:38AM -0700, Shawn O. Pearce wrote: And the pack-order versus idx-order for the bitmaps is still up in the air. Do we have numbers on the on-disk sizes of the resulting EWAHs? I did not see any presented in this thread, and I am very interested in this aspect of the series. The path hash cache should be taking about 9.9M of disk space, but I recall reading the bitmap file is 8M. I don't understand. I don't know there the 8M number came from, or if it was on the kernel repo. My bitmap-enabled pack of linux-2.6 (about 3.2M objects) using Vicent's patches looks like: $ du -sh * 42M pack-9ea76831aec6c49c5ff42509a2a2ce97da13c5ad.bitmap 87M pack-9ea76831aec6c49c5ff42509a2a2ce97da13c5ad.idx 630Mpack-9ea76831aec6c49c5ff42509a2a2ce97da13c5ad.pack Packing the same repo with jgit debug-gc (jgit 3.0.0) yields: $ du -sh * 3.0Mpack-2478783825733a1f1012f0087a0b5a92aa7437d8.bitmap 82M pack-2478783825733a1f1012f0087a0b5a92aa7437d8.idx 585Mpack-2478783825733a1f1012f0087a0b5a92aa7437d8.pack 4.8Mpack-f61fb76112372288923be7a0464476892dfebe3e.idx 97M pack-f61fb76112372288923be7a0464476892dfebe3e.pack If we assume that 12M of that is name-hash, that's still an order of magnitude larger. For reference, jgit created 327 bitmaps (according to its progress eye candy), and Vicent's patches generated 385. So that explains some of the increase, but the per-bitmap size is still much larger. The path hash cache may still be required, Colby and I have been debating the merits of having the data available for delta compression vs. the increase in memory required to hold it. I guess this is not an option for JGit, but for C git, an mmap-able name-hash file means we can just fault in the pages mentioning objects we actually need it for. And its use can be completely optional; in fact, it doesn't even need to be inside the .bitmap file (though I cannot think of a reason it would be useful outside of having bitmaps). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Off-line deverloper workflow?
Jean-Noël Avila avila...@gmail.com writes: For a short time, I had the same issue. We came up using git bundle to bundle changes and exchange them via email. The setup was to work in two separate branches. The roaming developper started a new branch when leaving. After some work, she sent the commits on her branch as a bundle file. The origin merged the branch extracted from the developper's bundle and sent back the bundle of the changes on origin since the last merge. No doubt that both side need to understand well the workflow of fetch/merge. Bundle files can be encrypted for better security. Yes, the above describes exactly what bundle was invented for. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not call built-in aliases from scripts
Sebastian Schuberth sschube...@gmail.com writes: On Thu, Jun 27, 2013 at 6:11 PM, Junio C Hamano gits...@pobox.com wrote: I vaguely recall that some people may have argued that git-foo is one less exec(2) when we left these in our scripted Porcelains, though, so on a platform with poorly performing fork/exec, this change may be seen as detrimental. I do not know it matters that much. But isn't this only true for commands that are not built-ins? I.e., ... Read I do not know it matters that much. again ;-). Git can evolve over time, and if that is really your plan, the first step you have to take is to revive the old discussion we had after v1.6.0: http://thread.gmane.org/gmane.comp.version-control.git/93511/focus=93825 and see if it is now a good idea. It could be in year 2014. It was not in 2008. Can I get around that discussion by adjusting the reasoning for the patch to mention consistency? Taking In principle I have no problem with this change, if nothing other than for consistency reasons. and I do have a huge issue with the justification in the proposed log message. together, I would reach the same conclusion ;-) I cannot apply this exact patch for an obvious and unrelated reason; it seems to have changes, e.g. git am option help, that do not have anything to do with the topic. Well, if the topic was consistency the changes would be related, or? The theme of the patch is Do not call built-in aliases from scripts (by the way, do not call them alias---it is confusing as they are not what people consider alias). diff --git a/git-am.sh b/git-am.sh index 9f44509..ad67194 100755 --- a/git-am.sh +++ b/git-am.sh @@ -16,8 +16,8 @@ s,signoff add a Signed-off-by line to the commit message u,utf8 recode into utf8 (default) k,keep pass -k flag to git-mailinfo keep-non-patch pass -b flag to git-mailinfo -keep-cr pass --keep-cr flag to git-mailsplit for mbox format -no-keep-cr do not pass --keep-cr flag to git-mailsplit independent of am.keepcr +keep-cr pass --keep-cr flag to git mailsplit for mbox format +no-keep-cr do not pass --keep-cr flag to git mailsplit independent of am.keepcr c,scissors strip everything before a scissors line whitespace= pass it through git-apply ignore-space-change pass it through git-apply As you were saying yourself, we tell users to prefer the git foo form, so we should also do so in the git am option help, IMHO. What does the above change to the options-help have anything to do with that theme? It does not seem to say anything about git foo vs git-foo? Confused... For a future reroll of this patch with only git-foo - 'git foo', I would appreciate an independent review by at least one set of eyes. It is very easy to blindly do this conversion with sed/perl and fail to spot misconversion before sending it out. At least the test suite (running on Linux) did not throw any failures at me after applying this patch. Passing test may be a necessary condition to convince yourself that the patch may not be so broken, but is not sufficient proof of correctness, which can only come from careful code inspection. In any case, thanks for working on this. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: contrib/mw-to-git/Git/Mediawiki.pm
Benoît Person benoit.per...@ensimag.fr writes: Oops, so sorry :/ It's defintely doable since the lowercase 'git' is only a bin-wrapper for git to ease development in contrib/mw-to-git/ . Hmph. Does it even need to be in-tree then? Is it insufficient to run ../../git from that directory instead? Junio, Matthieu : should I resend a new version of my serie which renames the 'git' (lowercase) file into something like 'git-dev' ? (some comments directly mentionning the 'git' (lowercase) file needs to be updated as well in the Makefile) Benoit -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: contrib/mw-to-git/Git/Mediawiki.pm
Matthieu Moy matthieu@grenoble-inp.fr writes: Benoît Person benoit.per...@ensimag.fr writes: Junio, Matthieu : should I resend a new version of my serie which renames the 'git' (lowercase) file into something like 'git-dev' ? I'd call it bin-wrapper/git, so that people can put bin-wrapper/ in their $PATH if needed, and by analogy with ../../bin-wrapper. If you go this way, don't forget to update the $0 relative paths. git-dev is OK with me too. (some comments directly mentionning the 'git' (lowercase) file needs to be updated as well in the Makefile) Yes. I just noticed that the script is not strictly a text file, ending with an incomplete line, by the way. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/5] git-remote-mediawiki: factoring code between git-remote-mediawiki and Git::Mediawiki
From: Benoit Person benoit.per...@ensimag.fr
For now, Git::Mediawiki contains nothing.
This first patch moves some of git-remote-mediawiki.perl's factorisable code
into Git::Mediawiki. In the same time, it removes the side effects of that code
and renames the fucntions and constants moved to expose a better API.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Git/Mediawiki.pm | 77 +-
contrib/mw-to-git/git-remote-mediawiki.perl | 85 +
2 files changed, 89 insertions(+), 73 deletions(-)
diff --git a/contrib/mw-to-git/Git/Mediawiki.pm
b/contrib/mw-to-git/Git/Mediawiki.pm
index 805f42a..47fe4f4 100644
--- a/contrib/mw-to-git/Git/Mediawiki.pm
+++ b/contrib/mw-to-git/Git/Mediawiki.pm
@@ -18,7 +18,82 @@ require Exporter;
@EXPORT = ();
# Methods which can be called as standalone functions as well:
-@EXPORT_OK = ();
+@EXPORT_OK = qw(clean_filename smudge_filename connect_maybe
+ EMPTY HTTP_CODE_OK);
+}
+
+# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
+use constant SLASH_REPLACEMENT = '%2F';
+
+# Used to test for empty strings
+use constant EMPTY = q{};
+
+# HTTP codes
+use constant HTTP_CODE_OK = 200;
+
+sub clean_filename {
+ my $filename = shift;
+ $filename =~ s{@{[SLASH_REPLACEMENT]}}{/}g;
+ # [, ], |, {, and } are forbidden by MediaWiki, even URL-encoded.
+ # Do a variant of URL-encoding, i.e. looks like URL-encoding,
+ # but with _ added to prevent MediaWiki from thinking this is
+ # an actual special character.
+ $filename =~ s/[\[\]\{\}\|]/sprintf(_%%_%x, ord($))/ge;
+ # If we use the uri escape before
+ # we should unescape here, before anything
+
+ return $filename;
+}
+
+sub smudge_filename {
+ my $filename = shift;
+ $filename =~ s{/}{@{[SLASH_REPLACEMENT]}}g;
+ $filename =~ s/ /_/g;
+ # Decode forbidden characters encoded in clean_filename
+ $filename =~ s/_%_([0-9a-fA-F][0-9a-fA-F])/sprintf('%c', hex($1))/ge;
+ return $filename;
+}
+
+sub connect_maybe {
+ my $wiki = shift;
+ if ($wiki) {
+ return $wiki;
+ }
+
+ my $remote_name = shift;
+ my $remote_url = shift;
+ my ($wiki_login, $wiki_password, $wiki_domain);
+
+ $wiki_login = Git::config(remote.${remote_name}.mwLogin);
+ $wiki_password = Git::config(remote.${remote_name}.mwPassword);
+ $wiki_domain = Git::config(remote.${remote_name}.mwDomain);
+
+ $wiki = MediaWiki::API-new;
+ $wiki-{config}-{api_url} = ${remote_url}/api.php;
+ if ($wiki_login) {
+ my %credential = (
+ 'url' = $remote_url,
+ 'username' = $wiki_login,
+ 'password' = $wiki_password
+ );
+ Git::credential(\%credential);
+ my $request = {lgname = $credential{username},
+ lgpassword = $credential{password},
+ lgdomain = $wiki_domain};
+ if ($wiki-login($request)) {
+ Git::credential(\%credential, 'approve');
+ print {*STDERR} qq(Logged in mediawiki user
$credential{username}.\n);
+ } else {
+ print {*STDERR} qq(Failed to log in mediawiki user
$credential{username} on ${remote_url}\n);
+ print {*STDERR} ' (error ' .
+ $wiki-{error}-{code} . ': ' .
+ $wiki-{error}-{details} . )\n;
+ Git::credential(\%credential, 'reject');
+ exit 1;
+ }
+ }
+
+ return $wiki;
}
1; # Famous last words
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 71baf8a..e40c034 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -14,6 +14,8 @@
use strict;
use MediaWiki::API;
use Git;
+use Git::Mediawiki qw(clean_filename smudge_filename connect_maybe
+ EMPTY HTTP_CODE_OK);
use DateTime::Format::ISO8601;
use warnings;
@@ -23,9 +25,6 @@ binmode STDOUT, ':encoding(UTF-8)';
use URI::Escape;
-# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
-use constant SLASH_REPLACEMENT = '%2F';
-
# It's not always possible to delete pages (may require some
# privileges). Deleted pages are replaced with this content.
use constant DELETED_CONTENT = [[Category:Deleted]]\n;
@@ -40,8 +39,6 @@ use constant NULL_SHA1 =
'';
# Used on Git's side to reflect empty edit messages on the wiki
use constant EMPTY_MESSAGE
[PATCH v6 1/5] git-remote-mediawiki: Introduction of Git::Mediawiki.pm
From: Benoit Person benoit.per...@ensimag.fr
Currently, the mw-to-git project contains only a remote helper
(git-remote-mediawiki.perl). To improve the user experience while
working with mediawiki remotes, new tools, designed for such cases,
should be created. To achieve this goal, the project needs a way to
share code between several scripts (remote helper, commands, ... ).
A perl package offers the best way to handle such case: Each script
can select what should be imported in its namespace. The package
namespacing limits the use of side effects in the shared code.
An alternate solution is to concatenate a toolset file with each
*.perl when 'make'-ing the project. In that scheme, everything is
imported in the script's namespace. Plus, files should be renamed in
order to chain to Git's toplevel makefile. Hence, this solution is not
acceptable.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Git/Mediawiki.pm | 24
contrib/mw-to-git/Makefile | 24 +---
2 files changed, 45 insertions(+), 3 deletions(-)
create mode 100644 contrib/mw-to-git/Git/Mediawiki.pm
diff --git a/contrib/mw-to-git/Git/Mediawiki.pm
b/contrib/mw-to-git/Git/Mediawiki.pm
new file mode 100644
index 000..805f42a
--- /dev/null
+++ b/contrib/mw-to-git/Git/Mediawiki.pm
@@ -0,0 +1,24 @@
+package Git::Mediawiki;
+
+use 5.008;
+use strict;
+use Git;
+
+BEGIN {
+
+our ($VERSION, @ISA, @EXPORT, @EXPORT_OK);
+
+# Totally unstable API.
+$VERSION = '0.01';
+
+require Exporter;
+
+@ISA = qw(Exporter);
+
+@EXPORT = ();
+
+# Methods which can be called as standalone functions as well:
+@EXPORT_OK = ();
+}
+
+1; # Famous last words
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index 1fb2424..a6f8b24 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -2,18 +2,36 @@
# Copyright (C) 2013
# Matthieu Moy matthieu@imag.fr
#
-## Build git-remote-mediawiki
+# To install, run Git's toplevel 'make install' then run:
+#
+# make install
+GIT_MEDIAWIKI_PM=Git/Mediawiki.pm
SCRIPT_PERL=git-remote-mediawiki.perl
GIT_ROOT_DIR=../..
HERE=contrib/mw-to-git/
SCRIPT_PERL_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL))
+INSTLIBDIR=$(shell $(MAKE) -C $(GIT_ROOT_DIR)/perl \
+-s --no-print-directory instlibdir)
all: build
-build install clean:
+install_pm:
+ install $(GIT_MEDIAWIKI_PM) $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM)
+
+build:
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+build-perl-script
+
+install: install_pm
$(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
-$@-perl-script
+install-perl-script
+
+clean:
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+clean-perl-script
+ rm $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM)
+
perlcritic:
perlcritic -2 *.perl
--
1.8.3.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/5] git-remote-mediawiki: new git bin-wrapper for developement
From: Benoit Person benoit.per...@ensimag.fr
The introduction of the Git::Mediawiki package makes it impossible to test,
without installation, git-remote-mediawiki and git-mw.
Using a git bin-wrapper enables us to define proper $GITPERLLIB to force the
use of the developement version of the Git::Mediawiki package, bypassing its
installed version if any.
An alternate solution was to 'install' all the files required at each build
but it pollutes the toplevel with untracked files.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Makefile| 6 ++
contrib/mw-to-git/bin-wrapper/git | 27 +++
2 files changed, 33 insertions(+)
create mode 100755 contrib/mw-to-git/bin-wrapper/git
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index a6f8b24..c5e66df 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -2,6 +2,12 @@
# Copyright (C) 2013
# Matthieu Moy matthieu@imag.fr
#
+# To build and test:
+#
+# make:
+# bin-wrapper/git mw preview Some_page.mw
+# bin-wrapper/git clone mediawiki::http://example.com/wiki/
+#
# To install, run Git's toplevel 'make install' then run:
#
# make install
diff --git a/contrib/mw-to-git/bin-wrapper/git
b/contrib/mw-to-git/bin-wrapper/git
new file mode 100755
index 000..aa714a5
--- /dev/null
+++ b/contrib/mw-to-git/bin-wrapper/git
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+# git executable wrapper script for Git-Mediawiki to run tests without
+# installing all the scripts and perl packages.
+
+# based on $GIT_ROOT_DIR/wrap-for-bin.sh
+
+
+GIT_ROOT_DIR=../../..
+GIT_EXEC_PATH=$(cd $(dirname $0) cd ${GIT_ROOT_DIR} pwd)
+
+echo $GIT_EXEC_PATH
+
+if test -n $NO_SET_GIT_TEMPLATE_DIR
+then
+ unset GIT_TEMPLATE_DIR
+else
+ GIT_TEMPLATE_DIR=$GIT_EXEC_PATH'/templates/blt'
+ export GIT_TEMPLATE_DIR
+fi
+# Hack to make the `use lib` call works with multiple paths
+GITPERLLIB=$GIT_EXEC_PATH'/contrib/mw-to-git:'$GIT_EXEC_PATH'/perl/blib/lib'
+GIT_TEXTDOMAINDIR=$GIT_EXEC_PATH'/po/build/locale'
+PATH=$GIT_EXEC_PATH'/contrib/mw-to-git:'$GIT_EXEC_PATH'/bin-wrappers:'$PATH
+export GIT_EXEC_PATH GITPERLLIB PATH GIT_TEXTDOMAINDIR
+
+exec ${GIT_EXEC_PATH}/git $@
--
1.8.3.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/5] git-remote-mediawiki: Adding git-mw command
From: Benoit Person benoit.per...@ensimag.fr
For now, git-remote-mediawiki is only a remote-helper. This patch adds a new
toolset script in which we will be able to build new tools for
git-remote-mediawiki.
This toolset uses a subcommand-mechanism to launch the proper action. For now
only the 'help' subcommand is implemented. It also provides some generic code
for the verbose and help command line options.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Makefile| 7 ++---
contrib/mw-to-git/git-mw.perl | 60 +++
2 files changed, 64 insertions(+), 3 deletions(-)
create mode 100755 contrib/mw-to-git/git-mw.perl
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
index c5e66df..775cb07 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -14,6 +14,7 @@
GIT_MEDIAWIKI_PM=Git/Mediawiki.pm
SCRIPT_PERL=git-remote-mediawiki.perl
+SCRIPT_PERL+=git-mw.perl
GIT_ROOT_DIR=../..
HERE=contrib/mw-to-git/
@@ -27,15 +28,15 @@ install_pm:
install $(GIT_MEDIAWIKI_PM) $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM)
build:
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
build-perl-script
install: install_pm
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
install-perl-script
clean:
- $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
clean-perl-script
rm $(INSTLIBDIR)/$(GIT_MEDIAWIKI_PM)
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
new file mode 100755
index 000..4a3e4a9
--- /dev/null
+++ b/contrib/mw-to-git/git-mw.perl
@@ -0,0 +1,60 @@
+#!/usr/bin/perl
+
+# Copyright (C) 2013
+# Benoit Person benoit.per...@ensimag.imag.fr
+# Celestin Matte celestin.ma...@ensimag.imag.fr
+# License: GPL v2 or later
+
+# Set of tools for git repo with a mediawiki remote.
+# Documentation bugtracker: https://github.com/moy/Git-Mediawiki/
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+
+# By default, use UTF-8 to communicate with Git and the user
+binmode STDERR, ':encoding(UTF-8)';
+binmode STDOUT, ':encoding(UTF-8)';
+
+# Global parameters
+my $verbose = 0;
+sub v_print {
+ if ($verbose) {
+ return print {*STDERR} @_;
+ }
+ return;
+}
+
+my %commands = (
+ 'help' =
+ [\help, {}, \help]
+);
+
+# Search for sub-command
+my $cmd = $commands{'help'};
+for (0..@ARGV-1) {
+ if (defined $commands{$ARGV[$_]}) {
+ $cmd = $commands{$ARGV[$_]};
+ splice @ARGV, $_, 1;
+ last;
+ }
+};
+GetOptions( %{$cmd-[1]},
+ 'help|h' = \{$cmd-[2]},
+ 'verbose|v' = \$verbose);
+
+# Launch command
+{$cmd-[0]};
+
+## Help Functions
##
+
+sub help {
+ print {*STDOUT} 'END';
+usage: git mw command args
+
+git mw commands are:
+helpDisplay help information about git mw
+END
+ exit;
+}
--
1.8.3.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/5] git-remote-mediawiki: new tool to preview local changes without pushing
From: Benoit Person benoit.per...@ensimag.fr
The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
preview content without pushing would be a nice thing to have.
changes from v5:
- Move git bin-wrapper 'git' into bin-wrapper/
- Updates its GIT_ROOT_DIR accordingly
- Updates the Makefile to use that new path in the comments
changes from v4:
- Rebase on latest master
- Typos in commits messages and code
- Comments in Makefile
- Factoring the conversion from relatives links to absolute ones in
`git mw preview`
- Updating that conversion mechanism to not convert links with an
anchor '#'.
- git-mw should be executable now.
changes from v3:
- Rewrite all commit messages.
- No more \ No newline at end of file.
- Rename GitMediawiki.pm into Git::Mediawiki.pm (so it moves GitMedawiki.pm
into Git/Mediawiki.pm).
- Remove from the Makefile the copy_pm target (see below 'Add a bin-wrapper').
- Use of 'install' insted of 'cp' in the Makefile.
- Comment on the install_pm target in the Makefile.
- Add a bin-wrapper for git to test scripts without 'make install'-ing them.
- Move verbose option handling from previous v3-4/4 (introduction of preview
tool) into v4-4/5 (introduction of git-mw).
- Refactor some code into subroutines to clean the global 'preview'
subroutine.
- Rewrite some error messages to make them more concise while still giving
the same amount of information.
- Use 'remote.${remote_name}.mwIDcontent' instead of 'mediawiki.IDContent'
as config item for the lookup ID used to combine template + new content.
- Remove comments about what's going on in the preview subroutine.
- Use 'clean_filename' (and not 'smudge_filename') in the preview tool to find
the correct mediawiki page name based on a filename.
- Remove space/tab mixup in the 'help' subroutine.
changes from v2:
- Add a way to test, without installation, code that uses GitMediawiki.pm.
- Move more constants to GitMediawiki.pm
- Remove the encapsulation of Git::config calls into a git_cmd_try one.
- Remove the --blob option, distinction between files and blobs is now
automatic.
- Add a --verbose option to output more information on what's going on.
- Rewrote the doc and the commit message.
- Rewrote of the template retrieving code (see 'get_template' sub).
- Use a configuration variable to define the content ID search in the
template. Default value set as 'bodyContent' since it seems more standard
than 'mw-content-text'.
- Final content is now saved as utf-8 to solve encoding issues.
- Perlcritic changes:
- Update for loops style to a more perlish one.
- All 'print's specify their output streams.
-- Same useless warnings left in git-remote-mediawiki.perl after
célestin's
work and git-mw.perl after this patch :) .
changes from v1:
- add new package GitMediawiki
- move some of git-remote-mediawiki functions into the package
- update git-remote-mediawiki to use those moved functions
- add a hacky-way to install it in the Makefile
- use it in the new git mw tool
- add a way to give to the preview tool blobs as argument
- add a fallback when the upstream's branch remote is not a mediawiki remote
- update the `autoload` option to use `git web--browse` and not `xdg-open`
- update the way we find the upstream's branch remote name
This serie is based on the 'master' branch merged with célestin's patch series.
[1] https://github.com/moy/Git-Mediawiki/issues/7
Benoit Person (5):
git-remote-mediawiki: Introduction of Git::Mediawiki.pm
git-remote-mediawiki: new git bin-wrapper for developement
git-remote-mediawiki: factoring code between git-remote-mediawiki and
Git::Mediawiki
git-remote-mediawiki: Adding git-mw command
git-remote-mediawiki: Add preview subcommand into git mw.
contrib/mw-to-git/Git/Mediawiki.pm | 100
contrib/mw-to-git/Makefile | 33 ++-
contrib/mw-to-git/bin-wrapper/git | 27 ++
contrib/mw-to-git/git-mw.perl | 368
contrib/mw-to-git/git-remote-mediawiki.perl | 85 +--
5 files changed, 537 insertions(+), 76 deletions(-)
create mode 100644 contrib/mw-to-git/Git/Mediawiki.pm
create mode 100755 contrib/mw-to-git/bin-wrapper/git
create mode 100755 contrib/mw-to-git/git-mw.perl
--
1.8.3.GIT
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/5] git-remote-mediawiki: Add preview subcommand into git mw.
From: Benoit Person benoit.per...@ensimag.fr
In the current state, a user of git-remote-mediawiki can edit the markup text
locally, but has to push to the remote wiki to see how the page is rendererd.
Add a new 'git mw preview' command that allows rendering the markup text on
the remote wiki without actually pushing any change on the wiki.
This uses Mediawiki's API to render the markup and inserts it in an actual
HTML page from the wiki so that CSS can be rendered properly. Most links
should work when the page exists on the remote.
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/Git/Mediawiki.pm | 3 +-
contrib/mw-to-git/git-mw.perl | 310 -
2 files changed, 311 insertions(+), 2 deletions(-)
diff --git a/contrib/mw-to-git/Git/Mediawiki.pm
b/contrib/mw-to-git/Git/Mediawiki.pm
index 47fe4f4..d13c4df 100644
--- a/contrib/mw-to-git/Git/Mediawiki.pm
+++ b/contrib/mw-to-git/Git/Mediawiki.pm
@@ -19,7 +19,7 @@ require Exporter;
# Methods which can be called as standalone functions as well:
@EXPORT_OK = qw(clean_filename smudge_filename connect_maybe
- EMPTY HTTP_CODE_OK);
+ EMPTY HTTP_CODE_OK HTTP_CODE_PAGE_NOT_FOUND);
}
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
@@ -30,6 +30,7 @@ use constant EMPTY = q{};
# HTTP codes
use constant HTTP_CODE_OK = 200;
+use constant HTTP_CODE_PAGE_NOT_FOUND = 404;
sub clean_filename {
my $filename = shift;
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
index 4a3e4a9..28df3ee 100755
--- a/contrib/mw-to-git/git-mw.perl
+++ b/contrib/mw-to-git/git-mw.perl
@@ -12,6 +12,14 @@ use strict;
use warnings;
use Getopt::Long;
+use URI::URL qw(url);
+use LWP::UserAgent;
+use HTML::TreeBuilder;
+
+use Git;
+use MediaWiki::API;
+use Git::Mediawiki qw(clean_filename connect_maybe
+ EMPTY HTTP_CODE_PAGE_NOT_FOUND);
# By default, use UTF-8 to communicate with Git and the user
binmode STDERR, ':encoding(UTF-8)';
@@ -26,9 +34,26 @@ sub v_print {
return;
}
+# Preview parameters
+my $file_name = EMPTY;
+my $remote_name = EMPTY;
+my $preview_file_name = EMPTY;
+my $autoload = 0;
+sub file {
+ $file_name = shift;
+ return $file_name;
+}
+
my %commands = (
'help' =
- [\help, {}, \help]
+ [\help, {}, \help],
+ 'preview' =
+ [\preview, {
+ '' = \file,
+ 'output|o=s' = \$preview_file_name,
+ 'remote|r=s' = \$remote_name,
+ 'autoload|a' = \$autoload
+ }, \preview_help]
);
# Search for sub-command
@@ -47,6 +72,288 @@ GetOptions( %{$cmd-[1]},
# Launch command
{$cmd-[0]};
+# Preview Functions
+
+sub preview_help {
+ print {*STDOUT} 'END';
+USAGE: git mw preview [--remote|-r remote name] [--autoload|-a]
+ [--output|-o output filename] [--verbose|-v]
+ blob | filename
+
+DESCRIPTION:
+Preview is an utiliy to preview local content of a mediawiki repo as if it was
+pushed on the remote.
+
+For that, preview searches for the remote name of the current branch's
+upstream if --remote is not set. If that remote is not found or if it
+is not a mediawiki, it lists all mediawiki remotes configured and asks
+you to replay your command with the --remote option set properly.
+
+Then, it searches for a file named 'filename'. If it's not found in
+the current dir, it will assume it's a blob.
+
+The content retrieved in the file (or in the blob) will then be parsed
+by the remote mediawiki and combined with a template retrieved from
+the mediawiki.
+
+Finally, preview will save the HTML result in a file. and autoload it
+in your default web browser if the option --autoload is present.
+
+OPTIONS:
+-r remote name, --remote remote name
+If the remote is a mediawiki, the template and the parse engine
+used for the preview will be those of that remote.
+If not, a list of valid remotes will be shown.
+
+-a, --autoload
+Try to load the HTML output in a new tab (or new window) of your
+default web browser.
+
+-o output filename, --output output filename
+Change the HTML output filename. Default filename is based on the
+input filename with its extension replaced by '.html'.
+
+-v, --verbose
+Show more information on what's going on under the hood.
+END
+ exit;
+}
+
+sub preview {
+ my $wiki;
+ my ($remote_url, $wiki_page_name);
+ my ($new_content, $template);
+ my $file_content;
+
+ if ($file_name eq EMPTY) {
+ die Missing file argument, see `git mw
Re: [PATCH] CYGWIN: Use a TCP socket for pipe()
Torsten Bögershausen tbo...@web.de writes: Work around issues that git hangs when doing fetch or pull under various protocols under CYGWIN. Replace pipe() with a socket connection using a TCP/IP. Introduce a new function socket_pipe() in compat/socket_pipe.c Sounds like sweeping the real problem, whatever it is, under rug. Is it that we are assuming a pipe buffer that is sufficiently large and expecting a write that we deem to be small enough not to block, causing a deadlock on a platform with very small pipe buffer, or something? + (void)setsockopt(fd_listen, SOL_SOCKET, SO_REUSEADDR, + (char*)reuse_on, sizeof(reuse_on)); Broken indentation. Either align (note: these are only to illustrate the column alignment; I am not encouraging to indent with leading SPs) the opening ( of the (char *) cast with f in fd_listen, like this, (void)setsockopt(fd_listen, SOL_SOCKET, SO_REUSEADDR, (char *)reuse_on, sizeof(reuse_on)); by a run of HT with minimum number of SP, or push the beginning of the second line past opening ( after setsockopt, like this, (void)setsockopt(fd_listen, SOL_SOCKET, SO_REUSEADDR, (char *)reuse_on, sizeof(reuse_on)); with a run of minimum number of HT without any SP. diff --git a/git-compat-util.h b/git-compat-util.h index c1f8a47..88632ab 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -176,6 +176,10 @@ int get_st_mode_bits(const char *path, int *mode); #endif #endif +int socket_pipe(int filedes[2]); +#ifdef GIT_USE_SOCKET_PIPE +#define pipe(a) socket_pipe(a) +#endif Shouldn't the function declaration be inside this #ifdef? /* used on Mac OS X */ #ifdef PRECOMPOSE_UNICODE #include compat/precompose_utf8.h -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: contrib/mw-to-git/Git/Mediawiki.pm
Hmph. Does it even need to be in-tree then? Is it insufficient to run ../../git from that directory instead? Well, the fact is we use Perl packages now (Git.pm and Git::Mediawiki.pm in contrib/mw-to-git/Git/). The way we build perl scripts in the toplevel's Makefile makes those packages accessible only in $GITPERLLIB if it's defined and defaults to $INSTLIBDIR to seek for installed version of those packages. We use a bin-wrapper to define that $GITPERLLIB variable so that the installed version gets bypassed by the one presents in the directory defined in $GITPERLLIB. I just noticed that the script is not strictly a text file, ending with an incomplete line, by the way. an incomplete line ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/5] git-remote-mediawiki: new git bin-wrapper for developement
benoit.per...@ensimag.fr writes:
diff --git a/contrib/mw-to-git/bin-wrapper/git
b/contrib/mw-to-git/bin-wrapper/git
new file mode 100755
index 000..aa714a5
--- /dev/null
+++ b/contrib/mw-to-git/bin-wrapper/git
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+# git executable wrapper script for Git-Mediawiki to run tests without
+# installing all the scripts and perl packages.
+
+# based on $GIT_ROOT_DIR/wrap-for-bin.sh
I really do not like the smell of this.
As far as I can tell, the only real reason why you need this and
cannot use ../../bin-wrappers/git directly is because the GITPERLLIB
it gives you only points at ../../perl/blib/lib and not this
directory.
Two possible alternatives:
- Is there a reason you would not want to install whatever Perl
modules you want to use via GITPERLLIB mechanism to
../../perl/blib/lib? Perhaps it will interfere with the real
installation step in ../../perl/Makefile? If that is the case,
then it is not a good idea, but otherwise, that would let you use
../../bin-wrappers/git as-is.
- Perhaps we could do:
GITPERLLIB=${GPLEXTRA+$GPLEXTRA:}@@BUILD_DIR@@/perl/blib/lib
in wrap-for-bin.sh, so that your instruction can become
GPLEXTRA=$(pwd) ../../bin-wrappers/git whatever-mw-thing
and you do not have to have this file? We would also need to
unset GPLEXTRA at the beginning of test-lib.sh if we were to do
this.
How does a developer (or user) use this script? From your Makefile
(e.g. make test)? Manually following some written instruction?
In either case, the latter option feels a lot more sensible
alternative without having to maintain this extra copy of wrap-for-bin
that can easily go out of sync.
+
+
+GIT_ROOT_DIR=../../..
+GIT_EXEC_PATH=$(cd $(dirname $0) cd ${GIT_ROOT_DIR} pwd)
+
+echo $GIT_EXEC_PATH
+
+if test -n $NO_SET_GIT_TEMPLATE_DIR
+then
+ unset GIT_TEMPLATE_DIR
+else
+ GIT_TEMPLATE_DIR=$GIT_EXEC_PATH'/templates/blt'
+ export GIT_TEMPLATE_DIR
+fi
+# Hack to make the `use lib` call works with multiple paths
+GITPERLLIB=$GIT_EXEC_PATH'/contrib/mw-to-git:'$GIT_EXEC_PATH'/perl/blib/lib'
+GIT_TEXTDOMAINDIR=$GIT_EXEC_PATH'/po/build/locale'
+PATH=$GIT_EXEC_PATH'/contrib/mw-to-git:'$GIT_EXEC_PATH'/bin-wrappers:'$PATH
+export GIT_EXEC_PATH GITPERLLIB PATH GIT_TEXTDOMAINDIR
+
+exec ${GIT_EXEC_PATH}/git $@
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not call built-in aliases from scripts
John Szakmeister j...@szakmeister.net writes: On Thu, Jun 27, 2013 at 1:27 PM, Junio C Hamano gits...@pobox.com wrote: [snip] diff --git a/git-am.sh b/git-am.sh index 9f44509..ad67194 100755 --- a/git-am.sh +++ b/git-am.sh @@ -16,8 +16,8 @@ s,signoff add a Signed-off-by line to the commit message u,utf8 recode into utf8 (default) k,keep pass -k flag to git-mailinfo keep-non-patch pass -b flag to git-mailinfo -keep-cr pass --keep-cr flag to git-mailsplit for mbox format -no-keep-cr do not pass --keep-cr flag to git-mailsplit independent of am.keepcr +keep-cr pass --keep-cr flag to git mailsplit for mbox format +no-keep-cr do not pass --keep-cr flag to git mailsplit independent of am.keepcr c,scissors strip everything before a scissors line whitespace= pass it through git-apply ignore-space-change pass it through git-apply As you were saying yourself, we tell users to prefer the git foo form, so we should also do so in the git am option help, IMHO. What does the above change to the options-help have anything to do with that theme? It does not seem to say anything about git foo vs git-foo? I initially missed it too, but `git-mailsplit` changed to `git mailsplit` in the help. Ahh, OK. Now that I look at it more, I see that `git-mailinfo` was missed and there's a `git-apply` towards the bottom. So I'm not sure it's helping the consistency argument. Hmph, true. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: contrib/mw-to-git/Git/Mediawiki.pm
Benoît Person benoit.per...@ensimag.fr writes: I just noticed that the script is not strictly a text file, ending with an incomplete line, by the way. an incomplete line ? http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_194 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Do not call built-in aliases from scripts
On Thu, Jun 27, 2013 at 11:05:09AM -0700, Junio C Hamano wrote: John Szakmeister j...@szakmeister.net writes: On Thu, Jun 27, 2013 at 1:27 PM, Junio C Hamano gits...@pobox.com wrote: [snip] diff --git a/git-am.sh b/git-am.sh index 9f44509..ad67194 100755 --- a/git-am.sh +++ b/git-am.sh @@ -16,8 +16,8 @@ s,signoff add a Signed-off-by line to the commit message u,utf8 recode into utf8 (default) k,keep pass -k flag to git-mailinfo keep-non-patch pass -b flag to git-mailinfo -keep-cr pass --keep-cr flag to git-mailsplit for mbox format -no-keep-cr do not pass --keep-cr flag to git-mailsplit independent of am.keepcr +keep-cr pass --keep-cr flag to git mailsplit for mbox format +no-keep-cr do not pass --keep-cr flag to git mailsplit independent of am.keepcr c,scissors strip everything before a scissors line whitespace= pass it through git-apply ignore-space-change pass it through git-apply As you were saying yourself, we tell users to prefer the git foo form, so we should also do so in the git am option help, IMHO. What does the above change to the options-help have anything to do with that theme? It does not seem to say anything about git foo vs git-foo? I initially missed it too, but `git-mailsplit` changed to `git mailsplit` in the help. Ahh, OK. That is rendered differently though, I don't think just having the plain text git command is as useful. It should either use the hyphenated form or enclose the text in quotes. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] lib-rebase: use write_script
Signed-off-by: Andrew Pimlott and...@pimlott.net
---
t/lib-rebase.sh |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 0b41155..7b42199 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -24,8 +24,7 @@
#-- Add a blank line.
set_fake_editor () {
- echo #!$SHELL_PATH fake-editor.sh
- cat fake-editor.sh \EOF
+ write_script fake-editor.sh \EOF
case $1 in
*/COMMIT_EDITMSG)
test -z $EXPECT_HEADER_COUNT ||
@@ -65,7 +64,6 @@ cat $1
EOF
test_set_editor $(pwd)/fake-editor.sh
- chmod a+x fake-editor.sh
}
# After set_cat_todo_editor, rebase -i will write the todo list (ignoring
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] lib-rebase: use write_script
Andrew Pimlott and...@pimlott.net writes:
Signed-off-by: Andrew Pimlott and...@pimlott.net
---
t/lib-rebase.sh |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 0b41155..7b42199 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -24,8 +24,7 @@
#-- Add a blank line.
set_fake_editor () {
- echo #!$SHELL_PATH fake-editor.sh
- cat fake-editor.sh \EOF
+ write_script fake-editor.sh \EOF
case $1 in
*/COMMIT_EDITMSG)
test -z $EXPECT_HEADER_COUNT ||
@@ -65,7 +64,6 @@ cat $1
EOF
test_set_editor $(pwd)/fake-editor.sh
- chmod a+x fake-editor.sh
}
# After set_cat_todo_editor, rebase -i will write the todo list (ignoring
Thanks, but it should probably be
write_script fake-editor.sh -\EOF
case $1 in
...
EOF
test_set_editor ...
if the aim is to modernize this part.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/5] git-remote-mediawiki: new git bin-wrapper for developement
Junio C Hamano gits...@pobox.com writes:
As far as I can tell, the only real reason why you need this and
cannot use ../../bin-wrappers/git directly is because the GITPERLLIB
it gives you only points at ../../perl/blib/lib and not this
directory.
Not only. You also need to have contrib/mw-to-git/ in the $PATH to be
able to run git mw and git clone mediawiki::
- Is there a reason you would not want to install whatever Perl
modules you want to use via GITPERLLIB mechanism to
../../perl/blib/lib?
A previous version of the patch did something like this. This previous
iterations had issues, IIRC with the PATH, but they should be solvable
(and most likely independant from the $GITPERLLIB).
Perhaps it will interfere with the real installation step in
../../perl/Makefile? If that is the case, then it is not a good idea,
but otherwise, that would let you use ../../bin-wrappers/git as-is.
I do not like very much the idea of having the same target directory for
two Makefiles, but that's just instinctive suspicion, not a real
argument.
- Perhaps we could do:
GITPERLLIB=${GPLEXTRA+$GPLEXTRA:}@@BUILD_DIR@@/perl/blib/lib
in wrap-for-bin.sh, so that your instruction can become
GPLEXTRA=$(pwd) ../../bin-wrappers/git whatever-mw-thing
You'd have to tweak the $PATH too, but that could be done by a very
small wrapper calling Git's bin-wrapper/git, like this:
GIT_ROOT_DIR=../../..
GIT_EXEC_PATH=$(cd $(dirname $0) cd ${GIT_ROOT_DIR} pwd)
GIT_MEDIAWIKI=$GIT_EXEC_PATH/contrib/mw-to-git
PATH=$GIT_MEDIAWIKI/contrib/mw-to-git:$PATH
GPLEXTRA=$GIT_MEDIAWIKI/contrib/mw-to-git
exec ${GIT_EXEC_PATH}/bin-wrappers/git $@
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] [PATCH] Do not call built-in aliases from scripts
Hi Sebastian,
On Thu, 27 Jun 2013, Sebastian Schuberth wrote:
Call built-in commands via the main executable (non-dashed form) without
relying on the aliases (dashed form) to be present. On some platforms,
e.g. those that do not properly support file system links, it is
inconvenient to ship the built-in aliases, so do not depend on their
presence.
A laudable goal!
diff --git a/git-am.sh b/git-am.sh
index 9f44509..ad67194 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,8 +16,8 @@ s,signoff add a Signed-off-by line to the commit
message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
keep-non-patch pass -b flag to git-mailinfo
-keep-cr pass --keep-cr flag to git-mailsplit for mbox format
-no-keep-cr do not pass --keep-cr flag to git-mailsplit
independent of am.keepcr
That looks to me as if an overly-long line in the diff (not your fault)
was wrapped in the mailer...
+keep-cr pass --keep-cr flag to git mailsplit for mbox format
At first, I wondered what changed in this line. But then I realized that
you separated git-mailsplit into git mailsplit. This is purely
nitpicking and I am almost ashamed to do so, but I think it might be
*slightly* easier to read if the git mailsplit was quoted.
Having said that, I think it is an important change.
It is a different change, philosophically, though, from changes like this
one:
@@ -174,7 +174,7 @@ It does not apply to blobs recorded in its index.)
then
GIT_MERGE_VERBOSITY=0 export GIT_MERGE_VERBOSITY
fi
-git-merge-recursive $orig_tree -- HEAD $his_tree || {
+git merge-recursive $orig_tree -- HEAD $his_tree || {
This change is code while the former change is documentation. It might be
prudent to split this commit into two, one for calls in scripts, one for
documentation. That way, we could carry the documentation change (which I
whole-heartedly agree with) in Git for Windows should upstream stop before
the fence.
diff --git a/git-archimport.perl b/git-archimport.perl
This file's diff would be less long if the code was a bit more DRY. But
your changes are sound.
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d13f02d..6718bad 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -18,7 +18,7 @@ $opt_h usage();
die Need at least one commit identifier! unless @ARGV;
-# Get git-config settings
+# Get git config settings
This is not as clear-cut as the changes above. I would tend to call it a
documentation change, though.
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index a0d796e..53c136f 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -358,10 +358,10 @@ sub req_Root
my @gitvars = `git config -l`;
if ($?) {
- print E problems executing git-config on the server -- this
is not a git repository or the PATH is not set correctly.\n;
+print E problems executing git config on the server -- this
is not a git repository or the PATH is not set correctly.\n;
print E \n;
print error 1 - problem executing git-config\n;
- return 0;
+return 0;
Please don't. I know, it is a whitespace error. But it makes reviewing
more tedious...
@@ -3936,14 +3936,14 @@ sub update
if ( defined ( $lastpicked ) )
{
-my $filepipe = open(FILELIST, '-|', 'git', 'diff-tree',
'-z', '-r', $lastpicked, $commit-{hash}) or die(Cannot call
git-diff-tree : $!);
+my $filepipe = open(FILELIST, '-|', 'git', 'diff-tree',
'-z', '-r', $lastpicked, $commit-{hash}) or die(Cannot call git
diff-tree : $!);
Likewise, this would be a documentation change. It is funny that the
open() did not require a change: apparently, your intended code fixes were
already started at some point, but not finished.
diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
index 8643f74..ec1d65b 100755
--- a/git-merge-octopus.sh
+++ b/git-merge-octopus.sh
@@ -97,7 +97,7 @@ do
if test $? -ne 0
then
echo Simple merge did not work, trying automatic merge.
- git-merge-index -o git-merge-one-file -a ||
+ git merge-index -o git-merge-one-file -a ||
This is a problem. 'git-merge-one-file' cannot be split here AFAICT.
Of course, we could teach merge-index to read *two* parameters instead of
one when it encounters git as the merge-program. But that would be as
hacky as the whole dashed-form business to begin with.
diff --git a/git-merge-resolve.sh b/git-merge-resolve.sh
index c9da747..343fe7b 100755
--- a/git-merge-resolve.sh
+++ b/git-merge-resolve.sh
@@ -45,7 +45,7 @@ then
exit 0
else
echo Simple merge failed, trying Automatic merge.
- if git-merge-index -o git-merge-one-file -a
+ if git merge-index -o git-merge-one-file -a
As above, with -octopus.
Apart from the split and the merge-one-file problem, absolutely no
objections
Re: [PATCH v6 2/5] git-remote-mediawiki: new git bin-wrapper for developement
As far as I can tell, the only real reason why you need this and
cannot use ../../bin-wrappers/git directly is because the GITPERLLIB
it gives you only points at ../../perl/blib/lib and not this
directory.
Plus (forgot to mention it in the other mail :/ ) it enables us to not
copy git-mw and git-remote-mediawiki at each make and stop us from
polluting the toplevel directory with those two scripts during
development.
Two possible alternatives:
- Is there a reason you would not want to install whatever Perl
modules you want to use via GITPERLLIB mechanism to
../../perl/blib/lib?
If we are making modifications to Git/Mediawiki.pm or even git-mw.perl
/ git-remote-mediawiki.perl, installing them without proper testing
beforehand seems wrong.
Perhaps it will interfere with the real
installation step in ../../perl/Makefile?
I don't think so, but I am not an expert on what's going on in
../../perl/Makefile.
If that is the case,
then it is not a good idea, but otherwise, that would let you use
../../bin-wrappers/git as-is.
- Perhaps we could do:
GITPERLLIB=${GPLEXTRA+$GPLEXTRA:}@@BUILD_DIR@@/perl/blib/lib
in wrap-for-bin.sh, so that your instruction can become
GPLEXTRA=$(pwd) ../../bin-wrappers/git whatever-mw-thing
and you do not have to have this file? We would also need to
unset GPLEXTRA at the beginning of test-lib.sh if we were to do
this.
How does a developer (or user) use this script? From your Makefile
(e.g. make test)? Manually following some written instruction?
In either case, the latter option feels a lot more sensible
alternative without having to maintain this extra copy of wrap-for-bin
that can easily go out of sync.
A developer uses it like any bin-wrapper : bin-wrapper/git mw preview
for instance. He can add it to its path while working on the scripts
etc ...
The best way to do it would be to factorise those new use cases
(adding new elements in $GITPERLLIB and $PATH) in the code that
generate bin-wrappers from wrap-for-bin.sh I think.
But it was weird to work on that in this serie which initial goal was
to add a preview tool for git-remote-mediawiki and ended up adding a
new perl package, a new 'git mw' command which handles subcommands,
...
In the end, this patch could be removed from the serie since it is
self-contained : it is not used by 3/5, 4/5, and 5/5.
Benoit
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] lib-rebase: use write_script
Excerpts from Junio C Hamano's message of Thu Jun 27 11:37:31 -0700 2013: Thanks, but it should probably be write_script fake-editor.sh -\EOF case $1 in ... EOF test_set_editor ... if the aim is to modernize this part. Yes, the goal is to make that file consistently use the current practice. (My syntax highlighting doesn't like it, but...) I should update the function I introduced first. I will re-submit the rebase -i --autosquash patch and wait for acceptance before trying to fix other things. Andrew -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Business Vorschlag
ACHTUNG Ich habe ein lukratives Geschäft Vorschlag von gemeinsamem Interesse mit Ihnen zu teilen, sondern die Übertragung von einer großen Geld von meiner Bank hier in Hongkong. Ich habe deinen Hinweis in meiner Suche nach jemandem, passend zu meinervorgeschlagenen Geschäftsbeziehung. Wenn Sie an einer Zusammenarbeit mit mir Kontakt mit mir durch meine private E-Mail interessiert ppwong...@yahoo.com.hk für weitere Details. Ihre erste Reaktion auf dieses Schreiben wird geschätzt. Mit freundlichen Grüßen, Mr. Peter Wong E-mail: ppwong...@yahoo.com.hk -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase -i: fixup fixup! fixup!
Excerpts from Andrew Pimlott's message of Wed Jun 26 17:20:32 -0700 2013:
Excerpts from Junio C Hamano's message of Wed Jun 26 16:48:57 -0700 2013:
Andrew Pimlott and...@pimlott.net writes:
In order to test this, I wrote a helper function to dump the rebase -i
todo list. Would you like this introduced in its own patch, or
combined? See below.
Depends on how involved the addition of the tests that actually use
the helper, but in general it would be a good idea to add it in the
first patch that actually uses it. Unused code added in a separate
patch will not point at that patch when bisecting, if that unused
code was broken from the beginning (not that I see anything
immediately broken in the code the following adds).
Ok, here is the complete commit, incorporating all feedback.
Updated for recommended here-doc style.
Andrew
---8---
Subject: [PATCH] rebase -i: handle fixup! fixup! in --autosquash
In rebase -i --autosquash, ignore all fixup! or squash! after the
first. This supports the case when a git commit --fixup/--squash referred
to an earlier fixup/squash instead of the original commit (whether
intentionally, as when the user expressly meant to note that the commit
fixes an earlier fixup; or inadvertently, as when the user meant to refer to
the original commit with :/msg; or out of laziness, as when the user could
remember how to refer to the fixup but not the original).
In the todo list, the full commit message is preserved, in case it provides
useful cues to the user. A test helper set_cat_todo_editor is introduced to
check this.
Helped-by: Thomas Rast tr...@inf.ethz.ch
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Andrew Pimlott and...@pimlott.net
---
Documentation/git-rebase.txt |4 ++-
git-rebase--interactive.sh | 25 ++
t/lib-rebase.sh | 14 +++
t/t3415-rebase-autosquash.sh | 57 ++
4 files changed, 94 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index c84854a..6b2e1c8 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -389,7 +389,9 @@ squash/fixup series.
the same ..., automatically modify the todo list of rebase -i
so that the commit marked for squashing comes right after the
commit to be modified, and change the action of the moved
- commit from `pick` to `squash` (or `fixup`).
+ commit from `pick` to `squash` (or `fixup`). Ignores subsequent
+ fixup! or squash! after the first, in case you referred to an
+ earlier fixup/squash with `git commit --fixup/--squash`.
+
This option is only valid when the '--interactive' option is used.
+
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f953d8d..169e876 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -689,8 +689,22 @@ rearrange_squash () {
case $message in
squash! *|fixup! *)
action=${message%%!*}
- rest=${message#*! }
- echo $sha1 $action $rest
+ rest=$message
+ prefix=
+ # skip all squash! or fixup! (but save for later)
+ while :
+ do
+ case $rest in
+ squash! *|fixup! *)
+ prefix=$prefix${rest%%!*},
+ rest=${rest#*! }
+ ;;
+ *)
+ break
+ ;;
+ esac
+ done
+ echo $sha1 $action $prefix $rest
# if it's a single word, try to resolve to a full sha1
and
# emit a second copy. This allows us to match on both
message
# and on sha1 prefix
@@ -699,7 +713,7 @@ rearrange_squash () {
if test -n $fullsha; then
# prefix the action to uniquely
identify this line as
# intended for full sha1 match
- echo $sha1 +$action $fullsha
+ echo $sha1 +$action $prefix $fullsha
fi
fi
esac
@@ -714,7 +728,7 @@ rearrange_squash () {
esac
printf '%s\n' $pick $sha1 $message
used=$used$sha1
- while read -r squash action msg_content
+ while read -r squash action msg_prefix msg_content
do
case $used in
* $squash *) continue ;;
@@
[PATCH] pull: require choice between rebase/merge on non-fast-forward pull
Because letting a trivial merge automatically handled by Git is so
easy with git pull, a person who is new to Git may not realize
that the project s/he is interacting with may prefer rebase
workflow. Add a safety valve to fail git pull that is not a
fast-forward until/unless the user expressed her preference between
the two.
Those who want the existing behaviour could just do
git config --global pull.rebase false
once, and they'd not even notice.
http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225326
for a full discussion.
The fallout from this change to test suite is not very pretty, though.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* This is not a serious inclusion proposal yet, but to see if
people are still interested in possibly helping new users.
git-pull.sh| 36 +-
t/annotate-tests.sh| 2 +-
t/t4013-diff-various.sh| 2 ++
t/t4200-rerere.sh | 2 ++
t/t5500-fetch-pack.sh | 6 +-
t/t5521-pull-options.sh| 2 ++
t/t5524-pull-msg.sh| 2 +-
t/t5700-clone-reference.sh | 4 ++--
t/t6022-merge-rename.sh| 2 ++
t/t6026-merge-attr.sh | 2 +-
t/t6029-merge-subtree.sh | 1 +
t/t6037-merge-ours-theirs.sh | 2 ++
t/t9114-git-svn-dcommit-merge.sh | 2 +-
t/t9400-git-cvsserver-server.sh| 2 +-
t/t9500-gitweb-standalone-no-errors.sh | 2 +-
15 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..4a6a863 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -41,13 +41,21 @@ test -f $GIT_DIR/MERGE_HEAD die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
log_arg= verbosity= progress= recurse_submodules= verify_signatures=
merge_args= edit=
+
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=${curr_branch#refs/heads/}
+
+# See if we are configured to rebase by default.
+# The value $rebase is, throughout the main part of the code:
+#(empty) - the user did not have any preference
+#true- the user told us to integrate by rebasing
+#flase - the user told us to integrate by merging
rebase=$(git config --bool branch.$curr_branch_short.rebase)
if test -z $rebase
then
rebase=$(git config --bool pull.rebase)
fi
+
dry_run=
while :
do
@@ -113,7 +121,8 @@ do
-r|--r|--re|--reb|--reba|--rebas|--rebase)
rebase=true
;;
- --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
+ --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase|\
+ -m|--m|--me|--mer|--merg|--merge)
rebase=false
;;
--recurse-submodules)
@@ -219,6 +228,7 @@ test true = $rebase {
fi
done
}
+
orig_head=$(git rev-parse -q --verify HEAD)
git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok
$@ || exit 1
test -z $dry_run || exit 0
@@ -264,6 +274,30 @@ case $merge_head in
die $(gettext Cannot rebase onto multiple branches)
fi
;;
+*)
+ # integrating with a single other history
+ merge_head=${merge_head% }
+ if test -z $rebase$no_ff$ff_only${squash#--no-squash}
+ test -n $orig_head
+ ! $(git merge-base --is-ancestor $orig_head $merge_head)
+ then
+echo 2 orig-head was $orig_head
+echo 2 merge-head is $merge_head
+git show 2 --oneline -s $orig_head $merge_head
+
+ die The pull does not fast-forward; please specify
+if you want to merge or rebase.
+
+Use either
+
+git pull --rebase
+git pull --merge
+
+You can also use 'git config pull.rebase true' (if you want --rebase) or
+'git config pull.rebase false' (if you want --merge) to set this once for
+this project and forget about it.
+ fi
+ ;;
esac
if test -z $orig_head
diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
index c56a77d..af02c6d 100644
--- a/t/annotate-tests.sh
+++ b/t/annotate-tests.sh
@@ -79,7 +79,7 @@ test_expect_success \
test_expect_success \
'merge-setup part 3' \
-'git pull . branch1'
+'git pull --merge . branch1'
test_expect_success \
'Two lines blamed on A, one on B, two on B1, one on B2' \
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index e77c09c..1ee2198 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -12,6 +12,8 @@ LF='
test_expect_success setup '
+ git config pull.rebase false
+
GIT_AUTHOR_DATE=2006-06-26 00:00:00 +
GIT_COMMITTER_DATE=2006-06-26 00:00:00 +
export GIT_AUTHOR_DATE GIT_COMMITTER_DATE
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index 7ff..0563357 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -25,6 +25,8 @@ test_description='git rerere
. ./test-lib.sh
Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions
On Thu, Jun 27, 2013 at 07:51:57AM +0200, Michael Haggerty wrote: In theory we can drop the safety valve; it should never actually happen. But I'd like to keep it there for working systems. Perhaps it is worth doing something like this: [...#ifdef out consistency check on cygwin when lock is held...] Yes, this would work. But, taking a step back, I think it is a bad idea to have an unreliable stat() masquerading as a real stat(). If we want to allow the use of an unreliable stat for certain purposes, let's have two stat() interfaces: * the true stat() (in this case I guess cygwin's slow-but-correct implementation) * some fast_but_maybe_unreliable_stat(), which would map to stat() on most platforms but might map to the Windows stat() on cygwin when so configured. Yeah, that makes sense to me. I don't have a particular opinion on which way to go, as I do not use cygwin at all (and on most platforms, the two stat interfaces would just both call stat()). I will leave it up to Cygwin folks whether they want to do something like my patch as a band-aid while working up the two-stat() solution. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] [PATCH] Do not call built-in aliases from scripts
Am 27.06.2013 14:47, schrieb Sebastian Schuberth:
diff --git a/git-archimport.perl b/git-archimport.perl
index 9cb123a..ed2c741 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
...
@@ -477,8 +477,8 @@ sub process_patchset_fast {
unlink @$del;
while (@$del) {
my @slice = splice(@$del, 0, 100);
-system('git-update-index','--remove','--',@slice) == 0 or
-die Error in git-update-index --remove: $!
$?\n;
+system('git update-index','--remove','--',@slice) == 0 or
+die Error in git update-index --remove: $!
$?\n;
Shouldn't this become 'git','update-index'?
}
}
@@ -496,25 +496,25 @@ sub process_patchset_fast {
}
# print moving $from $to;
rename($from, $to) or die Error renaming '$from' '$to': $!\n;
-system('git-update-index','--remove','--',$from) == 0 or
-die Error in git-update-index --remove: $!
$?\n;
-system('git-update-index','--add','--',$to) == 0 or
-die Error in git-update-index --add: $! $?\n;
+system('git update-index','--remove','--',$from) == 0 or
+die Error in git update-index --remove: $!
$?\n;
+system('git update-index','--add','--',$to) == 0 or
+die Error in git update-index --add: $! $?\n;
Twice here, too.
}
}
if (my $add = $ps-{new_files}) {
while (@$add) {
my @slice = splice(@$add, 0, 100);
-system('git-update-index','--add','--',@slice) == 0 or
-die Error in git-update-index --add: $! $?\n;
+system('git update-index','--add','--',@slice) == 0 or
+die Error in git update-index --add: $! $?\n;
Again.
}
}
if (my $mod = $ps-{modified_files}) {
while (@$mod) {
my @slice = splice(@$mod, 0, 100);
-system('git-update-index','--',@slice) == 0 or
+system('git update-index','--',@slice) == 0 or
Ditto.
-- Hannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: snip +# See if we are configured to rebase by default. +# The value $rebase is, throughout the main part of the code: +#(empty) - the user did not have any preference +#true- the user told us to integrate by rebasing +#flase - the user told us to integrate by merging s/flase/false And isn't all config settings documented somewhere? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
Assorted minor edits: On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: Because letting a trivial merge automatically handled by Git is so Maybe: Because letting Git handle a trivial merge automatically is so… that the project s/he is interacting with may prefer rebase workflow. Add a safety valve to fail git pull that is not a Maybe (adding an a): a rebase workflow. Cheers, 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 signature.asc Description: OpenPGP digital signature
Re: [PATCH] lib-rebase: use write_script
Andrew Pimlott and...@pimlott.net writes: I should update the function I introduced first. I will re-submit the rebase -i --autosquash patch and wait for acceptance before trying to fix other things. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rebase -i: fixup fixup! fixup!
Andrew Pimlott and...@pimlott.net writes:
Updated for recommended here-doc style.
Thanks.
+test_auto_fixup_fixup () {
+ git reset --hard base
+ echo 1 file1
+ git add -u
+ test_tick
+ git commit -m $1! first
+ echo 2 file1
+ git add -u
+ test_tick
+ git commit -m $1! $2! first
+ git tag final-$1-$2
+ test_tick
+ (
+ set_cat_todo_editor
+ test_must_fail git rebase --autosquash -i HEAD actual
+ cat expected EOF
+pick $(git rev-parse --short HEAD^^^) first commit
+$1 $(git rev-parse --short HEAD^) $1! first
+$1 $(git rev-parse --short HEAD) $1! $2! first
+pick $(git rev-parse --short HEAD^^) second commit
+EOF
+ test_cmp expected actual
Two issues here, which I'll locally amend (no need to resend):
cat expected -EOF
pick ...
...
EOF
test_cmp expected actual
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
W. Trevor King wk...@tremily.us writes: Assorted minor edits: On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: Because letting a trivial merge automatically handled by Git is so Maybe: Because letting Git handle a trivial merge automatically is so… that the project s/he is interacting with may prefer rebase workflow. Add a safety valve to fail git pull that is not a Maybe (adding an a): a rebase workflow. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
LOANS @3%
WE OFFER LOANS @3% INTEREST RATE FOR BUSINESS AND PRIVATE PURPOSES.APPLY NOW WITH: FILL AND RETURN Name: === Amount needed: === Duration: == Sex === Purpose: === Mobile number: == -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions
Jeff King p...@peff.net writes: But, taking a step back, I think it is a bad idea to have an unreliable stat() masquerading as a real stat(). If we want to allow the use of an unreliable stat for certain purposes, let's have two stat() interfaces: * the true stat() (in this case I guess cygwin's slow-but-correct implementation) * some fast_but_maybe_unreliable_stat(), which would map to stat() on most platforms but might map to the Windows stat() on cygwin when so configured. Yeah, that makes sense to me. I don't have a particular opinion on which way to go, as I do not use cygwin at all (and on most platforms, the two stat interfaces would just both call stat()). I will leave it up to Cygwin folks whether they want to do something like my patch as a band-aid while working up the two-stat() solution. I think in the longer term two-stat solution is a good thing. 0117c2f0 (Make core.sharedRepository work under cygwin 1.7, 2013-03-23) introduced get_st_mode_bits() to work around another glitch in the fast-but-cheating-and-unreliable replacement, which we may be able to revert once it is done. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: Because letting a trivial merge automatically handled by Git is so easy with git pull, a person who is new to Git may not realize that the project s/he is interacting with may prefer rebase workflow. Or they may not even realize that they've just merged an unrelated branch at all, dragging in a thousand unrelated commits which they accidentally push to a central repository without looking, contaminating future branches based on the central repostitory without drastic rebase surgery ;). I just saw one of these earlier this week. * This is not a serious inclusion proposal yet, but to see if people are still interested in possibly helping new users. What needs to happen to make it serious? I'm happy to help. Cheers, 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 signature.asc Description: OpenPGP digital signature
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
W. Trevor King wk...@tremily.us writes: On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote: Because letting a trivial merge automatically handled by Git is so easy with git pull, a person who is new to Git may not realize that the project s/he is interacting with may prefer rebase workflow. Or they may not even realize that they've just merged an unrelated branch at all, dragging in a thousand unrelated commits which they accidentally push to a central repository without looking, contaminating future branches based on the central repostitory without drastic rebase surgery ;). I just saw one of these earlier this week. I am not sure running pull and integrate other's work in random branches is something the proposed (not by me) change would help to prevent from happening. Your accident user could have just been on a 'maint' branch, pulled the 'master' branch which would fast-forward and then pushed the result back to 'maint', contaminating the shared 'maint' branch with commits that do not match the purpose of it, which is to hold only fixes without enhancements. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
Junio C Hamano gits...@pobox.com writes: Because letting a trivial merge automatically handled by Git is so easy with git pull, a person who is new to Git may not realize that the project s/he is interacting with may prefer rebase workflow. Add a safety valve to fail git pull that is not a fast-forward until/unless the user expressed her preference between the two. IMHO, that would be terrible for beginners. My experience with many beginners/students is: they run git pull to get changes from their co-workers, don't read the messages. When there's no conflict, it's OK, Git creates the merge commit and they continue working. When there are conflicts, they fix it (or not), and forget to commit, continue working, and commit when they really need to, later. That's bad: mixing merges with actual changes is terrible. But that works. And that's a very common mistake in my experience :-(. Now, give the same user as above git pull --rebase. rebase may stop because of conflicts, the user may fix it, but then if the user continues working, he's on a detached HEAD with a rebase ongoing. Some of the changes went away, they may come back one day if the user runs git rebase --continue. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Jun 2013, #09; Thu, 27)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. There are quite a few fixes already on 'master' that needed merging down to 'maint'; I'll be tagging 1.8.3.2 shortly. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * bc/checkout-tracking-name-plug-leak (2013-06-18) 2 commits (merged to 'next' on 2013-06-23 at 35f8f85) + t/t9802: explicitly name the upstream branch to use as a base + builtin/checkout.c: don't leak memory in check_tracking_name Plug a small leak in checkout. * bc/http-keep-memory-given-to-curl (2013-06-19) 1 commit (merged to 'next' on 2013-06-23 at cf91828) + http.c: don't rewrite the user:passwd string multiple times Older cURL wanted piece of memory we call it with to be stable, but we updated the auth material after handing it to a call. * fg/submodule-non-ascii-path (2013-06-20) 2 commits (merged to 'next' on 2013-06-20 at 122c0b2) + t7400: test of UTF-8 submodule names pass under Mac OS (merged to 'next' on 2013-06-17 at a0b9fa3) + handle multibyte characters in name Many git submodule operations do not work on a submodule at a path whose name is not in ASCII. * jk/add-i-custom-diff-algo (2013-06-23) 2 commits (merged to 'next' on 2013-06-24 at 42e7894) + add -i: add extra options at the right place in diff command line (merged to 'next' on 2013-06-17 at 48d5d4e) + add--interactive: respect diff.algorithm * jk/pull-into-dirty-unborn (2013-06-20) 2 commits (merged to 'next' on 2013-06-23 at ab4b111) + pull: merge into unborn by fast-forwarding from empty tree + pull: update unborn branch tip after index git pull into nothing trashed local changes that were in the index, and this avoids it. * kb/diff-blob-blob-doc (2013-06-18) 1 commit (merged to 'next' on 2013-06-20 at 34e896a) + Documentation: Move git diff blob blob * mm/merge-in-dirty-worktree-doc (2013-06-18) 1 commit (merged to 'next' on 2013-06-20 at 21b3267) + Documentation/git-merge.txt: weaken warning about uncommited changes * mm/push-force-is-dangerous (2013-06-18) 1 commit (merged to 'next' on 2013-06-20 at a6a8913) + Documentation/git-push.txt: explain better cases where --force is dangerous * mt/send-email-cc-match-fix (2013-06-20) 2 commits (merged to 'next' on 2013-06-23 at a2656b3) + send-email: sanitize author when writing From line + send-email: add test for duplicate utf8 name Logic used by git-send-email to suppress cc mishandled names that need RFC2047 quoting. * ph/builtin-srcs-are-in-subdir-these-days (2013-06-18) 1 commit (merged to 'next' on 2013-06-20 at 7507a48) + fix builtin-* references to be builtin/* * rr/cherry-pick-fast-forward-reflog-message (2013-06-19) 1 commit (merged to 'next' on 2013-06-24 at 8b6e9d8) + sequencer: write useful reflog message for fast-forward The reflog message created when git cherry-pick fast-forwarded did not say anything but cherry-pick, but it now says cherry-pick: fast-forward. * rr/rebase-stash-store (2013-06-17) 5 commits (merged to 'next' on 2013-06-23 at 2398dad) + rebase: use 'git stash store' to simplify logic + stash: introduce 'git stash store' + stash: simplify option parser for create + stash doc: document short form -p in synopsis + stash doc: add a warning about using create Finishing touches for the git rebase --autostash feature introduced earlier. * tr/maint-apply-non-git-patch-parsefix (2013-06-21) 1 commit (merged to 'next' on 2013-06-24 at 50583a5) + apply: carefully strdup a possibly-NULL name Fix for the codepath to parse patches that add new files, generated by programs other than Git. THis is an old breakage in v1.7.11 and will need to be merged down to the maintanance tracks. * vl/typofix (2013-06-19) 1 commit (merged to 'next' on 2013-06-23 at a057524) + random typofixes (committed missing a 't', successful missing an 's') * wk/doc-git-has-grown (2013-06-23) 1 commit (merged to 'next' on 2013-06-23 at 256263d) + user-manual: Update download size for Git and the kernel * ys/cygstart (2013-06-21) 1 commit (merged to 'next' on 2013-06-24 at 822d9ca) + web--browse: support /usr/bin/cygstart on Cygwin On Cygwin, recognize cygstart as a possible way to start a web browser (used in help -w and instaweb among others). -- [New Topics] * bp/mediawiki-preview (2013-06-26) 5 commits - git-remote-mediawiki: Add preview subcommand into git mw. - git-remote-mediawiki: Adding git-mw command - git-remote-mediawiki: factoring code between git-remote-mediawiki and Git::Mediawiki - git-remote-mediawiki: new git bin-wrapper for developement - git-remote-mediawiki: Introduction of Git::Mediawiki.pm *
Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions
Jeff King wrote: On Wed, Jun 26, 2013 at 10:45:48PM +0100, Ramsay Jones wrote: [ ... ] I think Michael's assessment above is missing one thing. It is true that a false positive is just a performance problem in most cases, as we unnecessarily reload the file, thinking it has changed. However, when we have taken a lock on the file, there is an additional safety measure: if we find the file is changed, we abort, as that should never happen (it means somebody else modified the file while we had it locked). But of course Cygwin's false positive here triggers the safety valve, and we die without even realizing that nothing changed. Indeed, this is exactly the situation. ATB, Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions
Michael Haggerty wrote: On 06/27/2013 12:35 AM, Jeff King wrote: [ ... ] I think Michael's assessment above is missing one thing. Peff is absolutely right; for some unknown reason I was thinking of the consistency check as having been already fixed. Well, the cygwin: Remove the Win32 l/stat() functions patch *does* fix the problem. :-D It's just a pity we can't use it on performance grounds. :( [...#ifdef out consistency check on cygwin when lock is held...] Yes, this would work. But, taking a step back, I think it is a bad idea to have an unreliable stat() masquerading as a real stat(). If we want to allow the use of an unreliable stat for certain purposes, let's have two stat() interfaces: * the true stat() (in this case I guess cygwin's slow-but-correct implementation) * some fast_but_maybe_unreliable_stat(), which would map to stat() on most platforms but might map to the Windows stat() on cygwin when so configured. By default the true stat() would always be used. It should have to be a conscious decision, taken only in specific, vetted scenarios, to use the unreliable stat. You have just described my second patch! :D For example, I can't imagine that checking the freshness of the index or of the packed-refs file is ever going to be a bottleneck, so there is no reason at all to use an unreliable stat() here. On the other hand, stat() seems definitely to be a bottleneck when testing for changes in a 100,000 file working tree, and here occasional mistakes might be considered acceptable. So for this purpose the unreliable stat() might be used. I have already written the first pass at this patch, but I'm having difficulty with naming (get_cached_stat_data, get_index_stat_data, get_stat_data, ... ;-) ATB, Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions
Torsten Bögershausen wrote: [ ... ] (And have a look how to improve the core.filemode) I don't understand this (parenthetical) comment; could you elaborate on this. This is probably wrong information: I had in mind that cygwin sets core.filemode=false, It does, see commit c869753e (Force core.filemode to false on Cygwin, 30-12-2006). which is quite annoying when exchanging .sh files with linux. Indeed, I used to build git with NO_TRUSTABLE_FILEMODE reset so that I wouldn't have to edit the config file by hand after a git-clone or git-init. But that seems to be wrong, a quick test shows that core.filemode=true. Hmm, it shouldn't - confused! Sorry for confusion. ATB Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions
Jeff King wrote:
On Wed, Jun 26, 2013 at 06:35:52PM -0400, Jeff King wrote:
I am curious how often Cygwin gives us the false positive. If it is
every time, then the check is not doing much good at all. Is it possible
for you to instrument stat_validity_check to report how often it does or
does not do anything useful?
Maybe like this:
diff --git a/read-cache.c b/read-cache.c
index d5201f9..19dcb69 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1958,6 +1958,14 @@ void stat_validity_clear(struct stat_validity *sv)
sv-sd = NULL;
}
+static int unchanged;
+static int attempts;
+static void print_stats(void)
+{
+ fprintf(stderr, stat data was unchanged %d/%d\n,
+ unchanged, attempts);
+}
+
int stat_validity_check(struct stat_validity *sv, const char *path)
{
struct stat st;
@@ -1966,7 +1974,16 @@ int stat_validity_check(struct stat_validity *sv,
const char *path)
return sv-sd == NULL;
if (!sv-sd)
return 0;
- return S_ISREG(st.st_mode) !match_stat_data(sv-sd, st);
+ if (!S_ISREG(st.st_mode))
+ return 0;
+ if (!attempts++)
+ atexit(print_stats);
+ if (!match_stat_data(sv-sd, st)) {
+ unchanged++;
+ return 1;
+ }
+ else
+ return 0;
}
void stat_validity_update(struct stat_validity *sv, int fd)
Running t3211 -v, I see things like:
stat data was unchanged 3/3
stat data was unchanged 20/20
stat data was unchanged 2/2
Deleted branch yadda (was d1ff1c9).
stat data was unchanged 8/8
ok 8 - peeled refs survive deletion of packed ref
I am curious if you will see 0/20 or 19/20 there on Cygwin.
Ah, no ... the problem is not as subtle as this! :-D
I'm sorry if I failed to mention that I already had a patch
to solve the problem, but that I *don't* want to submit it,
since it is ugly and just serves to spread the madness! ;-)
This is why I tried the cygwin: Remove the Win32 l/stat()
functions patch first; I think this is the correct approach
to fixing this problem (and similar *future* problems).
However, since that is no longer an option, on performance
grounds, I have other ideas I want to try. (see later email)
The schizophrenic stat functions have caused many subtle
problems, but this is not one of them; a brick to the head
would be more subtle. The problem is caused by the stat
validity code using both fstat() and stat() on the same
file. Note that there is no Win32 implementation of the
fstat() function.
So, a solution to the problem would be to provide just such
an implementation. The patch to do so is given below, just
for illustration purposes.
This fixes the failures to t3210, t3211 and t5500. However, I
have not run the full test suite. This may cause some further
*subtle* problems (just grep for fstat and consider what may
go wrong; I have not done that), especially when you consider
that cygwin has the UNRELIABLE_FSTAT build variable set.
HTH
ATB,
Ramsay Jones
-- 8 --
Subject: [PATCH] cygwin: Add an Win32 fstat implementation
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
compat/cygwin.c | 41 +
compat/cygwin.h | 3 +++
2 files changed, 44 insertions(+)
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 91ce5d4..d59c9fb 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -4,6 +4,7 @@
#include sys/errno.h
#include win32.h
#include ../git-compat-util.h
+#include io.h
#include ../cache.h /* to read configuration */
/*
@@ -100,6 +101,38 @@ static int cygwin_stat(const char *path, struct stat *buf)
return do_stat(path, buf, stat);
}
+static int cygwin_fstat(int fd, struct stat *buf)
+{
+ HANDLE fh = (HANDLE)get_osfhandle(fd);
+ BY_HANDLE_FILE_INFORMATION fdata;
+
+ if (fh == INVALID_HANDLE_VALUE) {
+ errno = EBADF;
+ return -1;
+ }
+ if (GetFileType(fh) != FILE_TYPE_DISK)
+ return (fstat)(fd, buf);
+ if (GetFileInformationByHandle(fh, fdata)) {
+ buf-st_dev = buf-st_rdev = 0; /* not used by Git */
+ buf-st_ino = 0;
+ buf-st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
+ buf-st_nlink = 1;
+ buf-st_uid = buf-st_gid = 0;
+#ifdef __CYGWIN_USE_BIG_TYPES__
+ buf-st_size = ((_off64_t)fdata.nFileSizeHigh 32) +
+ fdata.nFileSizeLow;
+#else
+ buf-st_size = (off_t)fdata.nFileSizeLow;
+#endif
+ buf-st_blocks = size_to_blocks(buf-st_size);
+ filetime_to_timespec(fdata.ftLastAccessTime, buf-st_atim);
+ filetime_to_timespec(fdata.ftLastWriteTime, buf-st_mtim);
+ filetime_to_timespec(fdata.ftCreationTime, buf-st_ctim);
+ return 0;
+ }
+ errno = EBADF;
+ return -1;
+}
/*
* At start up, we are trying to determine whether Win32
Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
On Thu, Jun 27, 2013 at 02:20:42PM -0700, Junio C Hamano wrote: Your accident user could have just been on a 'maint' branch, [snip] By the time I talk people into using a 'maint' branch, we'll probably have already passed the 'accidental pull and push' stage ;). This will certainly reduce the risk in any case. Cheers, 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 signature.asc Description: OpenPGP digital signature
Re: [git] Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
On Fri, Jun 28, 2013 at 12:16:53AM +0200, Matthieu Moy wrote: IMHO, that would be terrible for beginners. My experience with many beginners/students is: they run git pull to get changes from their co-workers, don't read the messages. I admit that I'd be happy with a config option that just disabled pull entirely (forcing people to fetch/merge explicitly) to avoid this type of beginner mistake. With an unconfigured pull.rebase, this patch does that for merge/rebase cases, while still letting folks pull when it's a clean fast forward (usually ok). I'd also be happy with an opt-in disable. The real solution would be to talk my group out of using a central shared repository or into using pull-free feature branches, but I don't see either on my horizon. Git doesn't need to change to mitigate sloppy-shared-repo problems, but having some sort of anti-pull configuration option would certainly help me out. Cheers, 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 signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 0/5] git-prompt: cleaning and improvement
Hi Junio, The merged result is ok! Thanks, Eduardo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] status: really ignore config with --porcelain
On Mon, Jun 24, 2013 at 11:16:56AM -0700, Junio C Hamano wrote:
diff --git a/builtin/commit.c b/builtin/commit.c
index 0da944f..a535eb2 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -111,12 +111,14 @@ static int show_ignored_in_status;
static const char *only_include_assumed;
static struct strbuf message = STRBUF_INIT;
-static enum {
+static enum status_format {
STATUS_FORMAT_NONE = 0,
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN
-} status_format;
+ STATUS_FORMAT_PORCELAIN,
+
+ STATUS_FORMAT_UNSPECIFIED
+} status_format = STATUS_FORMAT_UNSPECIFIED;
I'm not sure why you need to add UNSPECIFIED here; the point of NONE is
that no format had yet been specified.
It looks like the only difference is that finalize_deferred_config
converts unspecified into NONE. But I think you can just use NONE for
both cases, and drop this hunk:
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
@@ -457,6 +459,9 @@ static int run_status(FILE *fp, const char *index_file,
const char *prefix, int
case STATUS_FORMAT_PORCELAIN:
wt_porcelain_print(s);
break;
+ case STATUS_FORMAT_UNSPECIFIED:
+ die(BUG: finalize_deferred_config() should have been called);
+ break;
case STATUS_FORMAT_NONE:
case STATUS_FORMAT_LONG:
wt_status_print(s);
You lose the assertion that finalize_deferred_config has been called,
but I think the resulting code would be simpler, as it drops this
die(BUG) state entirely. Am I missing something?
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/1] cygwin: Remove the Win32 l/stat() functions
On 06/27/2013 06:58 PM, Ramsay Jones wrote: This is why I tried the cygwin: Remove the Win32 l/stat() functions patch first; I think this is the correct approach to fixing this problem (and similar *future* problems). I adamantly agree. However, since that is no longer an option, on performance grounds, I have other ideas I want to try. (see later email) Correctness first, speed later. 1) Keep the patch to remove the buggy and unreliable stat / lstat. 2) We fix the remaining test failures. 3) With the test suite passing, stat optimization(s) that cause no failures / regressions can be accepted. With the msys/mingw git available for years now, there really is not a reason to make Cygwin's git violate the Posix expectations of that platform. msys makes no such promises, so is the right tool for those on Windows who just want git as fast as possible on Windows (still slow) and don't care about file modes, softlinks, etc. I'm keeping your patch in my tree. Mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] CYGWIN: Use a TCP socket for pipe()
On 06/27/2013 01:38 PM, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: Work around issues that git hangs when doing fetch or pull under various protocols under CYGWIN. Replace pipe() with a socket connection using a TCP/IP. Introduce a new function socket_pipe() in compat/socket_pipe.c Sounds like sweeping the real problem, whatever it is, under rug. Is it that we are assuming a pipe buffer that is sufficiently large and expecting a write that we deem to be small enough not to block, causing a deadlock on a platform with very small pipe buffer, or something? There were issues in early v1.7 Cygwin release for overlapping I/O such that the pipe was sometimes terminated early resulting in data loss. If the pipe implementation in Cygwin is still a problem a good test case sent to the Cygwin developers would be the right approach rather than a one-off patch in git to try to work around a current platform bug. Note - I do not see random hangs with the stat/lstat hack removed, rather the sole test suite hang I see is repeatable in t0008.sh. So, if the patch remains, we may be able to run this remaining hang to ground. Mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] status: really ignore config with --porcelain
Jeff King p...@peff.net writes: You lose the assertion that finalize_deferred_config has been called, but I think the resulting code would be simpler, as it drops this die(BUG) state entirely. Am I missing something? Probably not. Depending on -z, NONE is sometimes converted to PORCELAIN and sometimes left as-is. I originally wanted to keep the unspecified state as long as possible so that this deferred config logic and the -z default logic can be kept separate. The final patch ended up folding that -z default logic into the same function, so it probably is saner to remove UNSPECIFIED. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
