* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Linus Torvalds @ 2006-03-19 19:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andreas Ericsson, Eric Wong, Martin Langhoff, git
In-Reply-To: <20060319191243.GB18185@pasky.or.cz>
On Sun, 19 Mar 2006, Petr Baudis wrote:
>
> (i) I _think_ that it would be less of a surprise if a branch would be
> checked first.
Yeah, I guess that's true.
> Actually, I'm almost inclined to suggest making Git fail violently in
> case of an ambiguous name.
Maybe not fail, but at least warn very loudly.
Linus
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Petr Baudis @ 2006-03-19 19:12 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Eric Wong, Linus Torvalds, Martin Langhoff, git
In-Reply-To: <44056BF1.6000109@op5.se>
Dear diary, on Wed, Mar 01, 2006 at 10:40:01AM CET, I got a letter
where Andreas Ericsson <ae@op5.se> said that...
> It already does. The search order is this, for a ref named 'foo':
> $GIT_DIR/foo
> $GIT_DIR/refs/foo
> $GIT_DIR/refs/tags/foo
> $GIT_DIR/refs/heads/foo
Actually, I've hit this recently when supporting an unhappy user on
#git, and I didn't manage to find anything in the archives (but perhaps
I missed it). Is there a particular reason why tags are checked first
than branches?
Why not:
(i) I _think_ that it would be less of a surprise if a branch would be
checked first.
(ii) E.g. Cogito output (cg-status -g) is very confusing when you have a
naming clash - cg-object-id foo will show tag commit ID, but cg-status -g
will say that the "foo" branch has a different commit ID (and it is
_right_).
(iii) Many operations will stop making sense (cg-merge foo, and even
cg-fetch foo will be confused), while in case of the opposite way I can't
think of any command still not making sense.
(iv) A security hole when you auto-fetch tags from remote repositories
- you could then be misled to merge something totally different when the
attacker will introduce a naming clash to your refs hierarchy.
Actually, I'm almost inclined to suggest making Git fail violently in
case of an ambiguous name.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [ANNOUNCE] qgit 1.1.1
From: Marco Costalba @ 2006-03-19 16:53 UTC (permalink / raw)
To: git; +Cc: proski
This is a maintenance release, mainly performance tweaks and small bug fixes.
To install use:
./configure
make
make install-strip
Or check the shipped README for detailed information.
To note are big speed-up in annotation and tree viewer browsing
See http://digilander.libero.it/mcostalba/ for download information.
Changelog
* add support for file annotations in multi-branch repos
* speed-up browsing with tree view open
* tree view: set in bold the names of modified files
* use a map instead of a list to speed-up path filtering
* add support for listing tags in a submenu in mainview context pop-up
* show StGIT patch names on the status bar (Pavel Roskin)
* use dark green pluses for applied StGIT patches (Pavel Roskin)
* more then double annotation speed
* add support for jumping to branches from pop-up menu
* remove setting 'Load file names in background'
* save cache file under ./git directory
* fix duplicate tags in the pop-up menu (Pavel Roskin)
Have fun
Marco
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Marco Costalba @ 2006-03-19 14:04 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git, junkio
In-Reply-To: <4d8e3fd30603190525o5a01fba8w5bcdedd064c213ec@mail.gmail.com>
On 3/19/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> On 3/19/06, Marco Costalba <mcostalba@gmail.com> wrote:
> >
>
> How about getting an account on kernel.org?
>
I don't think I have the credentials to ask for ;-)
> Anyway, here is what I did:
> paolo@Italia:~$ cg-clone
> http://digilander.libero.it/mcostalba/scm/qgit.git qgit defaulting to
>
> Why am I getting this error?
> error: File 8dea03519e75f47da91108330dde3043defddd60
> (http://digilander.libero.i
> t/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
> corr upt
>
Because http server of digilander.libero.it instead of responding with
404 code (page not
found) sends a not standard html page as answer. To see the page just point
your browser to:
http://digilander.libero.it /mcostalba/scm/qgit.git/objects/8d/ea03519e75f47d
Git does not understand object is missing and thinks what site sends
_is_ the requested
object and then founds that is (of course) corrupted.
Marco
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Paolo Ciarrocchi @ 2006-03-19 13:25 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, junkio
In-Reply-To: <e5bfff550603190252n7e3e1cbbp94e3f15c92f12d07@mail.gmail.com>
On 3/19/06, Marco Costalba <mcostalba@gmail.com> wrote:
> Hi all,
Ciao Marco,
> I have set a git repository on a hosted public site:
> http://digilander.libero.it/mcostalba/scm/qgit.git
>
> I cannot run any process (read git-daemon) on that site, so git-clone uses
> a 'dumb server' type protocol and this is what I got.
>
> $ git clone http://digilander.libero.it/mcostalba/scm/qgit.git
> error: File 8dea03519e75f47da91108330dde3043defddd60
> (http://digilander.libero.it/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
> corrupt
> Getting pack list for http://digilander.libero.it/mcostalba/scm/qgit.git/
> Getting index for pack fe1f3586b38e70e963de47f31379ef170adc5ca9
> Getting pack fe1f3586b38e70e963de47f31379ef170adc5ca9
> which contains 8dea03519e75f47da91108330dde3043defddd60
> walk 8dea03519e75f47da91108330dde3043defddd60
> walk ec47dab590fb838ba2be7af5bf9aa46d9f2e502d
>
> -------------- cut ------------------------
>
> walk 907d47e836f4f174386d02d21e38aeafc1e79626
> walk 5d3454248bbb3aaba080057dc9666a3c3aaeca1f
> $
>
> The above mentioned error belongs to git requests a non existing object
> (8dea03519e75f47da91108330dde3043defddd60) _and_ the site answers with
> a pre-canned 'page not found' html page instead of reporting 404 error.
>
> After some research I found it is quite common for public hosting
> sites to use a pre-canned
> 'Sorry, no page here' html stuff instead of 404.
>
> So my request is if it is possible for git to _learn_ this and to
> avoid been fooled by
> these kind of public sites.
>
How about getting an account on kernel.org?
Anyway, here is what I did:
paolo@Italia:~$ cg-clone
http://digilander.libero.it/mcostalba/scm/qgit.git qgit defaulting to
local storage area
Fetching head...
Fetching objects...
error: File 8dea03519e75f47da91108330dde3043defddd60
(http://digilander.libero.i
t/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
corr upt
Getting pack list for http://digilander.libero.it/mcostalba/scm/qgit.git/
Getting index for pack fe1f3586b38e70e963de47f31379ef170adc5ca9
Getting pack fe1f3586b38e70e963de47f31379ef170adc5ca9
which contains 8dea03519e75f47da91108330dde3043defddd60
Fetching tags...
Missing tag qgit-0.93... retrieved
Missing tag qgit-0.94... retrieved
Missing tag qgit-0.94.1... retrieved
Missing tag qgit-0.95.1... retrieved
Missing tag qgit-0.96... retrieved
Missing tag qgit-0.96.1... retrieved
Missing tag qgit-0.97... retrieved
Missing tag qgit-0.97.1... retrieved
Missing tag qgit-0.97.2... retrieved
Missing tag qgit-1.0... retrieved
Missing tag qgit-1.1rc1... retrieved
Missing tag qgit-1.1rc3... retrieved
New branch: 8dea03519e75f47da91108330dde3043defddd60
Cloned to qgit/ (origin
http://digilander.libero.it/mcostalba/scm/qgit.git available as branch
"origin")
Why am I getting this error?
error: File 8dea03519e75f47da91108330dde3043defddd60
(http://digilander.libero.i
t/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
corr upt
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Cloning from sites with 404 overridden
From: Marco Costalba @ 2006-03-19 10:52 UTC (permalink / raw)
To: git; +Cc: junkio
Hi all,
I have set a git repository on a hosted public site:
http://digilander.libero.it/mcostalba/scm/qgit.git
I cannot run any process (read git-daemon) on that site, so git-clone uses
a 'dumb server' type protocol and this is what I got.
$ git clone http://digilander.libero.it/mcostalba/scm/qgit.git
error: File 8dea03519e75f47da91108330dde3043defddd60
(http://digilander.libero.it/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
corrupt
Getting pack list for http://digilander.libero.it/mcostalba/scm/qgit.git/
Getting index for pack fe1f3586b38e70e963de47f31379ef170adc5ca9
Getting pack fe1f3586b38e70e963de47f31379ef170adc5ca9
which contains 8dea03519e75f47da91108330dde3043defddd60
walk 8dea03519e75f47da91108330dde3043defddd60
walk ec47dab590fb838ba2be7af5bf9aa46d9f2e502d
-------------- cut ------------------------
walk 907d47e836f4f174386d02d21e38aeafc1e79626
walk 5d3454248bbb3aaba080057dc9666a3c3aaeca1f
$
The above mentioned error belongs to git requests a non existing object
(8dea03519e75f47da91108330dde3043defddd60) _and_ the site answers with
a pre-canned 'page not found' html page instead of reporting 404 error.
After some research I found it is quite common for public hosting
sites to use a pre-canned
'Sorry, no page here' html stuff instead of 404.
So my request is if it is possible for git to _learn_ this and to
avoid been fooled by
these kind of public sites.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Jan-Benedict Glaw @ 2006-03-19 10:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git, Jon Loeliger
In-Reply-To: <7vr74zqhhi.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
On Sat, 2006-03-18 18:46:17 -0800, Junio C Hamano <junkio@cox.net> wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
> > [nice description of Git's packing heuristics]
> >
> > Junio, are there any specific reasons why this hasn't been applied
> > yet?
>
> Funny. I was just re-reading it last night.
>
> It _is_ amusing, but I am not sure if it should go to
> technical/. If properly digested and reorganized, I suspect
> that the document would become 1/3 of its current length.
But surely it should go somewhere, in its current form. It's *such* a
nice reading and really amusing, so it shouldn't get lost.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 3/3] git.el: Added a function to diff against the other heads in a merge.
From: Alexandre Julliard @ 2006-03-19 9:06 UTC (permalink / raw)
To: git
git-diff-file-merge-head generates a diff against the first merge
head, or with a prefix argument against the nth head. Bound to `d h'
by default.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
92478446cf5718ee76acaced75ff41416329a509
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 5496a1b..ebd00ef 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -767,6 +767,16 @@ The default is to fall back to the git r
(git-setup-diff-buffer
(apply #'git-run-command-buffer "*git-diff*" "diff-index" "-p" "-M" "HEAD" "--" (git-get-filenames files)))))
+(defun git-diff-file-merge-head (arg)
+ "Diff the marked file(s) against the first merge head (or the nth one with a numeric prefix)."
+ (interactive "p")
+ (let ((files (git-marked-files))
+ (merge-heads (git-get-merge-heads)))
+ (unless merge-heads (error "No merge in progress"))
+ (git-setup-diff-buffer
+ (apply #'git-run-command-buffer "*git-diff*" "diff-index" "-p" "-M"
+ (or (nth (1- arg) merge-heads) "HEAD") "--" (git-get-filenames files)))))
+
(defun git-diff-unmerged-file (stage)
"Diff the marked unmerged file(s) against the specified stage."
(let ((files (git-marked-files)))
@@ -959,6 +969,7 @@ The default is to fall back to the git r
(define-key diff-map "=" 'git-diff-file)
(define-key diff-map "e" 'git-diff-file-idiff)
(define-key diff-map "E" 'git-find-file-imerge)
+ (define-key diff-map "h" 'git-diff-file-merge-head)
(define-key diff-map "m" 'git-diff-file-mine)
(define-key diff-map "o" 'git-diff-file-other)
(setq git-status-mode-map map)))
--
1.2.4.g9c5a7
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 2/3] git.el: Get the default user name and email from the repository config.
From: Alexandre Julliard @ 2006-03-19 9:05 UTC (permalink / raw)
To: git
If user name or email are not set explicitly, get them from the
user.name and user.email configuration values before falling back to
the Emacs defaults.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
ac4b54cc4019abdb92cd0fbbf7c644976227fea0
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index cf650da..5496a1b 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -59,14 +59,14 @@
(defcustom git-committer-name nil
"User name to use for commits.
-The default is to fall back to `add-log-full-name' and then `user-full-name'."
+The default is to fall back to the repository config, then to `add-log-full-name' and then to `user-full-name'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Name")))
(defcustom git-committer-email nil
"Email address to use for commits.
-The default is to fall back to `add-log-mailing-address' and then `user-mail-address'."
+The default is to fall back to the git repository config, then to `add-log-mailing-address' and then to `user-mail-address'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Email")))
@@ -203,6 +203,7 @@ The default is to fall back to `add-log-
"Return the name to use as GIT_COMMITTER_NAME."
; copied from log-edit
(or git-committer-name
+ (git-repo-config "user.name")
(and (boundp 'add-log-full-name) add-log-full-name)
(and (fboundp 'user-full-name) (user-full-name))
(and (boundp 'user-full-name) user-full-name)))
@@ -211,6 +212,7 @@ The default is to fall back to `add-log-
"Return the email address to use as GIT_COMMITTER_EMAIL."
; copied from log-edit
(or git-committer-email
+ (git-repo-config "user.email")
(and (boundp 'add-log-mailing-address) add-log-mailing-address)
(and (fboundp 'user-mail-address) (user-mail-address))
(and (boundp 'user-mail-address) user-mail-address)))
@@ -268,6 +270,11 @@ The default is to fall back to `add-log-
(git-get-string-sha1
(git-call-process-env-string nil "rev-parse" rev)))
+(defun git-repo-config (key)
+ "Retrieve the value associated to KEY in the git repository config file."
+ (let ((str (git-call-process-env-string nil "repo-config" key)))
+ (and str (car (split-string str "\n")))))
+
(defun git-symbolic-ref (ref)
"Wrapper for the git-symbolic-ref command."
(let ((str (git-call-process-env-string nil "symbolic-ref" ref)))
--
1.2.4.g9c5a7
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 1/3] git.el: More robust handling of subprocess errors when returning strings.
From: Alexandre Julliard @ 2006-03-19 9:05 UTC (permalink / raw)
To: git
Make sure that functions that call a git process and return a string
always return nil when the subprocess failed.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 29 +++++++++++++----------------
1 files changed, 13 insertions(+), 16 deletions(-)
66a8d3c3e63a2d4178c9917e0c172bdc2cbec3bb
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 5135e36..cf650da 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -148,6 +148,12 @@ The default is to fall back to `add-log-
(append (git-get-env-strings env) (list "git") args))
(apply #'call-process "git" nil buffer nil args)))
+(defun git-call-process-env-string (env &rest args)
+ "Wrapper for call-process that sets environment strings, and returns the process output as a string."
+ (with-temp-buffer
+ (and (eq 0 (apply #' git-call-process-env t env args))
+ (buffer-string))))
+
(defun git-run-process-region (buffer start end program args)
"Run a git process with a buffer region as input."
(let ((output-buffer (current-buffer))
@@ -189,8 +195,9 @@ The default is to fall back to `add-log-
(defun git-get-string-sha1 (string)
"Read a SHA1 from the specified string."
- (let ((pos (string-match "[0-9a-f]\\{40\\}" string)))
- (and pos (substring string pos (match-end 0)))))
+ (and string
+ (string-match "[0-9a-f]\\{40\\}" string)
+ (match-string 0 string)))
(defun git-get-committer-name ()
"Return the name to use as GIT_COMMITTER_NAME."
@@ -259,18 +266,12 @@ The default is to fall back to `add-log-
(defun git-rev-parse (rev)
"Parse a revision name and return its SHA1."
(git-get-string-sha1
- (with-output-to-string
- (with-current-buffer standard-output
- (git-call-process-env t nil "rev-parse" rev)))))
+ (git-call-process-env-string nil "rev-parse" rev)))
(defun git-symbolic-ref (ref)
"Wrapper for the git-symbolic-ref command."
- (car
- (split-string
- (with-output-to-string
- (with-current-buffer standard-output
- (git-call-process-env t nil "symbolic-ref" ref)))
- "\n")))
+ (let ((str (git-call-process-env-string nil "symbolic-ref" ref)))
+ (and str (car (split-string str "\n")))))
(defun git-update-ref (ref val &optional oldval)
"Update a reference by calling git-update-ref."
@@ -285,11 +286,7 @@ The default is to fall back to `add-log-
(defun git-write-tree (&optional index-file)
"Call git-write-tree and return the resulting tree SHA1 as a string."
(git-get-string-sha1
- (with-output-to-string
- (with-current-buffer standard-output
- (git-call-process-env t
- (if index-file `(("GIT_INDEX_FILE" . ,index-file)) nil)
- "write-tree")))))
+ (git-call-process-env-string (and index-file `(("GIT_INDEX_FILE" . ,index-file))) "write-tree")))
(defun git-commit-tree (buffer tree head)
"Call git-commit-tree with buffer as input and return the resulting commit SHA1."
--
1.2.4.g9c5a7
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Jon Loeliger @ 2006-03-19 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7vr74zqhhi.fsf@assigned-by-dhcp.cox.net>
So, like, the other day Junio C Hamano mumbled:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
> > [nice description of Git's packing heuristics]
> >
> > Junio, are there any specific reasons why this hasn't been applied
> > yet?
>
> Funny. I was just re-reading it last night.
>
> It _is_ amusing, but I am not sure if it should go to
> technical/.
You know, I don't know what to do with it either. :-)
I have half a notion to submit it to the OLS call for
"Linux Essay Contest" just to see what happens....
> If properly digested and reorganized, I suspect
> that the document would become 1/3 of its current length.
I suppose I could do a round of that, if you would like. :-)
I should either drink more or less, I can't tell which...
jdl
^ permalink raw reply
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Junio C Hamano @ 2006-03-19 2:46 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: junkio, git, Jon Loeliger
In-Reply-To: <20060319003255.GA17124@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> [nice description of Git's packing heuristics]
>
> Junio, are there any specific reasons why this hasn't been applied
> yet?
Funny. I was just re-reading it last night.
It _is_ amusing, but I am not sure if it should go to
technical/. If properly digested and reorganized, I suspect
that the document would become 1/3 of its current length.
^ permalink raw reply
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Fredrik Kuivinen @ 2006-03-19 0:32 UTC (permalink / raw)
To: junkio; +Cc: git, Jon Loeliger
In-Reply-To: <E1FEyx7-0007vo-Je@jdl.com>
On Thu, Mar 02, 2006 at 07:19:29PM -0600, Jon Loeliger wrote:
>
> Signed-off-by: Jon Loeliger <jdl@jdl.com>
>
> ---
>
> Documentation/technical/pack-heuristics.txt | 466 +++++++++++++++++++++++++++
> 1 files changed, 466 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/technical/pack-heuristics.txt
>
> 0cbbcac437be6f8a0249f6cf83b90a6fe9d2362e
> diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt
> new file mode 100644
> index 0000000..eaab3ee
> --- /dev/null
> +++ b/Documentation/technical/pack-heuristics.txt
> @@ -0,0 +1,466 @@
> + Concerning Git's Packing Heuristics
> + ===================================
> +
[nice description of Git's packing heuristics]
Junio, are there any specific reasons why this hasn't been applied
yet?
- Fredrik
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-18 23:21 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86bqw51z5q.fsf@blue.stonehenge.com>
I tested the version in today's "next" branch, and it fixes the
problem for me in my tests that use my day-job CVS repository as
a guinea pig.
In case you are not brave enough to switch to "next" wholesale,
but are kind enough to try out the relevant cvsimport change for
us, here is a patch that applies on top of "master". It is a
roll-up of two commits on my jc/cvsimport branch.
-- >8 --
cvsimport: honor -i and non -i upon subsequent imports
Documentation says -i is "import only", so without it,
subsequent import should update the current branch and working
tree files in a sensible way.
"A sensible way" defined by this commit is "act as if it is a
git pull from foreign repository which happens to be CVS not
git". So:
- If importing into the current branch (note that cvsimport
requires the tracking branch is pristine -- you checked out
the tracking branch but it is your responsibility not to make
your own commits there), fast forward the branch head and
match the index and working tree using two-way merge, just
like "git pull" does.
- If importing into a separate tracking branch, update that
branch head, and merge it into your current branch, again,
just like "git pull" does.
Initial round of the updated code read the tip of the current
branch before and after the import runs, but forgot to chomp
what we read from the command. The read-tree command did not
them with the trailing LF. This has been fixed.
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 02d1928..3728294 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -453,6 +453,7 @@ chdir($git_tree);
my $last_branch = "";
my $orig_branch = "";
my %branch_date;
+my $tip_at_start = undef;
my $git_dir = $ENV{"GIT_DIR"} || ".git";
$git_dir = getwd()."/".$git_dir unless $git_dir =~ m#^/#;
@@ -487,6 +488,7 @@ unless(-d $git_dir) {
$last_branch = "master";
}
$orig_branch = $last_branch;
+ $tip_at_start = `git-rev-parse --verify HEAD`;
# populate index
system('git-read-tree', $last_branch);
@@ -873,7 +875,22 @@ if (defined $orig_git_index) {
# Now switch back to the branch we were in before all of this happened
if($orig_branch) {
- print "DONE; you may need to merge manually.\n" if $opt_v;
+ print "DONE.\n" if $opt_v;
+ if ($opt_i) {
+ exit 0;
+ }
+ my $tip_at_end = `git-rev-parse --verify HEAD`;
+ if ($tip_at_start ne $tip_at_end) {
+ for ($tip_at_start, $tip_at_end) { chomp; }
+ print "Fetched into the current branch.\n" if $opt_v;
+ system(qw(git-read-tree -u -m),
+ $tip_at_start, $tip_at_end);
+ die "Fast-forward update failed: $?\n" if $?;
+ }
+ else {
+ system(qw(git-merge cvsimport HEAD), "refs/heads/$opt_o");
+ die "Could not merge $opt_o into the current branch.\n" if $?;
+ }
} else {
$orig_branch = "master";
print "DONE; creating $orig_branch branch\n" if $opt_v;
^ permalink raw reply related
* Re: [PATCH] git-merge: New options `--no-fast-forward' and `--direct'.
From: Junio C Hamano @ 2006-03-18 22:53 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <7vmzfns9c6.fsf@assigned-by-dhcp.cox.net>
>From nobody Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sat Mar 18 14:50:53 2006 -0800
Subject: [PATCH] git-merge knows some strategies want to skip trivial merges
Most notably "ours". Also this makes sure we do not record
duplicated parents on the parent list of the resulting commit.
This is based on Mark Wooding's work, but does not change the UI
nor introduce new flags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* How about this instead? It looks larger than it really is
because strategy-defaulting code needed to get moved around.
git-merge.sh | 67 +++++++++++++++++++++++++++++++++++-----------------------
1 files changed, 40 insertions(+), 27 deletions(-)
313093ea6d29bbce5977556645eb5946dbfb211e
diff --git a/git-merge.sh b/git-merge.sh
index cc0952a..78ab422 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -11,11 +11,15 @@ LF='
'
all_strategies='recursive octopus resolve stupid ours'
-default_strategies='recursive'
+default_twohead_strategies='recursive'
+default_octopus_strategies='octopus'
+no_trivial_merge_strategies='ours'
use_strategies=
+
+index_merge=t
if test "@@NO_PYTHON@@"; then
all_strategies='resolve octopus stupid ours'
- default_strategies='resolve'
+ default_twohead_strategies='resolve'
fi
dropsave() {
@@ -90,8 +94,6 @@ do
shift
done
-test "$#" -le 2 && usage ;# we need at least two heads.
-
merge_msg="$1"
shift
head_arg="$1"
@@ -99,6 +101,8 @@ head=$(git-rev-parse --verify "$1"^0) ||
shift
# All the rest are remote heads
+test "$#" = 0 && usage ;# we need at least one remote head.
+
remoteheads=
for remote
do
@@ -108,6 +112,27 @@ do
done
set x $remoteheads ; shift
+case "$use_strategies" in
+'')
+ case "$#" in
+ 1)
+ use_strategies="$default_twohead_strategies" ;;
+ *)
+ use_strategies="$default_octopus_strategies" ;;
+ esac
+ ;;
+esac
+
+for s in $use_strategies
+do
+ case " $s " in
+ *" $no_trivial_merge_strategies "*)
+ index_merge=f
+ break
+ ;;
+ esac
+done
+
case "$#" in
1)
common=$(git-merge-base --all $head "$@")
@@ -118,18 +143,21 @@ case "$#" in
esac
echo "$head" >"$GIT_DIR/ORIG_HEAD"
-case "$#,$common,$no_commit" in
-*,'',*)
+case "$index_merge,$#,$common,$no_commit" in
+f,*)
+ # We've been told not to try anything clever. Skip to real merge.
+ ;;
+?,*,'',*)
# No common ancestors found. We need a real merge.
;;
-1,"$1",*)
+?,1,"$1",*)
# If head can reach all the merge then we are up to date.
- # but first the most common case of merging one remote
+ # but first the most common case of merging one remote.
echo "Already up-to-date."
dropsave
exit 0
;;
-1,"$head",*)
+?,1,"$head",*)
# Again the most common case of merging one remote.
echo "Updating from $head to $1"
git-update-index --refresh 2>/dev/null
@@ -139,11 +167,11 @@ case "$#,$common,$no_commit" in
dropsave
exit 0
;;
-1,?*"$LF"?*,*)
+?,1,?*"$LF"?*,*)
# We are not doing octopus and not fast forward. Need a
# real merge.
;;
-1,*,)
+?,1,*,)
# We are not doing octopus, not fast forward, and have only
# one common. See if it is really trivial.
git var GIT_COMMITTER_IDENT >/dev/null || exit
@@ -188,17 +216,6 @@ esac
# We are going to make a new commit.
git var GIT_COMMITTER_IDENT >/dev/null || exit
-case "$use_strategies" in
-'')
- case "$#" in
- 1)
- use_strategies="$default_strategies" ;;
- *)
- use_strategies=octopus ;;
- esac
- ;;
-esac
-
# At this point, we need a real merge. No matter what strategy
# we use, it would operate on the index, possibly affecting the
# working tree, and when resolved cleanly, have the desired tree
@@ -270,11 +287,7 @@ done
# auto resolved the merge cleanly.
if test '' != "$result_tree"
then
- parents="-p $head"
- for remote
- do
- parents="$parents -p $remote"
- done
+ parents=$(git-show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge $result_commit, made by $wt_strategy."
dropsave
--
1.2.4.g2fc2
^ permalink raw reply related
* Re: [PATCH] git-merge: New options `--no-fast-forward' and `--direct'.
From: Junio C Hamano @ 2006-03-18 21:59 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060318101941.8941.52615.stgit@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> These options disable some of git-merge's optimizations.
While there is no question about the part of the proposed change
to bypass "trivial merge", I do not necessarily agree with
"skipping fast forward" part.
It is a problem that "ours" strategy cannot be used as a way to
recover from the "accidentally rewound head" situation, because
it is prevented from running under certain conditions as you
described. But that does not necessarily mean we should make
"ours" to work in these situations.
You accidentally discarded B while somebody picked it up:
o---o
/ \
---o---o---A---o---o---B
^your head
Now you would want to recover. With your patch, it would create
this:
o---o
/ \
---o---o---A---o---o---B
\ \
------------M
^your updated head,
having the same tree as A
But recording A as a parent of M is not necessary. I think what
we want to have as the result is this instead:
o---o
/ \
---o---o---A---o---o---B---M
^your updated head,
having the same tree as A
This is something you cannot do within the current git-merge
framework; it is set up to either just fast forward or make a
multi-parent commit. You would want have a "revert to this
state" [*1*], something like this (assuming you have rewound to
A and currently your index matches A):
$ git reset --soft B
$ git commit -m 'Discard A..B and revert to A'
I did "ours" primarily as a demonstration of a funky thing
people could do with the consolidated driver "git-merge". I did
not have a useful use-case in mind back then, but it turned out
to be the ideal way to recover from "accidentally rewound head"
situation, except that making a merge commit between A and B is
not always the way to recover from it. If we wanted to, we
could have a special purpose command that does "git merge -s
ours" if there will be a new commit, otherwise the above two
commands sequence if it will be a fast forward, but the
"recovering from accidentally rewound head" _is_ really a
special purpose, so I do not know if it is worth it.
In your cover letter, you talked about using --no-fast-forward
to collapse your sole topic branch into your master branch. I
do not think smudging the development history with extra merge
commits for that is justfied either. There is no reason for you
to discard your topic branch heads after you merged them into
master. If they get in the way of your normal workflow, you can
stash them away as tags that you do not usually see in "git
branch" output [*2*].
Also I am already unhappy that git-merge knows about the
specifics of strategies [*3*], e.g. it knows octopus is
currently the only strategy that can do more than two heads.
Your patch gives more strategy specific knowledge to it, but I
do not know how to avoid it.
[Footnotes]
*1* As opposed to "git revert X" which means "revert the effect
of commit X", you would want "revert to the state X".
*2* I keep some of my old topic branch heads under
.git/tags/attic/.
*3* Another thing I am unhappy about is the list of available
strategies. I initially wanted to allow users to write their
own merge strategies and have them on their PATH (not even
necessarily in GIT_EXEC_PATH directory), so that you can do a
git-merge-mdw secretly, keep it in ~mdw/bin and cook it for a
while using yourself as a guinea pig, and then share that with
the community later, _without_ touching git-merge.
^ permalink raw reply
* Re: [PATCH] 3% tighter packs for free
From: Junio C Hamano @ 2006-03-18 19:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603181315060.4889@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> Tried that long ago. As BLK_SIZE is increased the adler32 cost, which
> has to be computed for every offset in the target buffer, increases
> accordingly. So you end up with both worse compression and more CPU
> usage.
Ah, I was not paying enough attention. I did not realize
destination scanning was done for every byte.
^ permalink raw reply
* Re: [PATCH] 3% tighter packs for free
From: Nicolas Pitre @ 2006-03-18 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtesxloi.fsf@assigned-by-dhcp.cox.net>
On Fri, 17 Mar 2006, Junio C Hamano wrote:
> Once you make it into a patch form, it is plainly obvious that
> this is a good optimization. Since our BLK_SIZE is 16 bytes,
> you are grabbing up to 15 more bytes (on average 8 more bytes or
> so) for every match after a partially modified block.
>
> Very nice. I wonder if a larger BLK_SIZE (say 32 bytes) would
> give us faster packing without losing much compression if we use
> this idea.
Tried that long ago. As BLK_SIZE is increased the adler32 cost, which
has to be computed for every offset in the target buffer, increases
accordingly. So you end up with both worse compression and more CPU
usage.
Nicolas
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Fredrik Kuivinen @ 2006-03-18 16:23 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <dbfc82860603180725w2eb3057ey17fa8d9dc746127@mail.gmail.com>
On Sat, Mar 18, 2006 at 04:25:04PM +0100, Nikolai Weibull wrote:
> On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> >
> > Based on the completion code for quilt in the Zsh distribution.
>
> Actually, there's an almost-complete implementation in 4.3 already.
> Written by me nonetheless. You can take a look and make suggestions
> if you like :-). I have an updated version to deal with post
> 1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
>
Oh, I didn't know about that.
<updates zsh>
Very nice! Much better than my crude cut-and-paste work.
Junio: Please don't apply the patch.
- Fredrik
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Nikolai Weibull @ 2006-03-18 16:14 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <4fb292fa0603180752r731c628eoa2b96fcd6ef43e0f@mail.gmail.com>
On 3/18/06, Bertrand Jacquin <beber.mailing@gmail.com> wrote:
> On 3/18/06, Nikolai Weibull <now@bitwi.se> wrote:
> > On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> > >
> > > Based on the completion code for quilt in the Zsh distribution.
> >
> > Actually, there's an almost-complete implementation in 4.3 already.
> > Written by me nonetheless. You can take a look and make suggestions
> > if you like :-). I have an updated version to deal with post
> > 1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
>
> Any plan do to this for cogito ?
Sure, and stgit as well, but I haven't gotten around to it. The idea
was to reuse as much as possible of the stuff that the three have in
common (like tags, references, and so on), but as I haven't used
either of the two (cogito and stgit) I haven't had a compelling reason
to sit down and do it.
nikolai
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Bertrand Jacquin @ 2006-03-18 15:52 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <dbfc82860603180725w2eb3057ey17fa8d9dc746127@mail.gmail.com>
On 3/18/06, Nikolai Weibull <now@bitwi.se> wrote:
> On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> >
> > Based on the completion code for quilt in the Zsh distribution.
>
> Actually, there's an almost-complete implementation in 4.3 already.
> Written by me nonetheless. You can take a look and make suggestions
> if you like :-). I have an updated version to deal with post
> 1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
Any plan do to this for cogito ?
>
> nikolai
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Nikolai Weibull @ 2006-03-18 15:25 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, junkio
In-Reply-To: <20060318145347.15128.85902.stgit@c165>
On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
>
> Based on the completion code for quilt in the Zsh distribution.
Actually, there's an almost-complete implementation in 4.3 already.
Written by me nonetheless. You can take a look and make suggestions
if you like :-). I have an updated version to deal with post
1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
nikolai
^ permalink raw reply
* [PATCH] Basic Zsh completion support
From: Fredrik Kuivinen @ 2006-03-18 14:53 UTC (permalink / raw)
To: git; +Cc: junkio
Based on the completion code for quilt in the Zsh distribution.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
.gitignore | 1 +
Makefile | 8 +++++++-
generate-zsh-compl.sh | 26 ++++++++++++++++++++++++++
3 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index b4355b9..1cf6ac0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -133,3 +133,4 @@ libgit.a
*.py[co]
config.mak
git-blame
+_git
diff --git a/Makefile b/Makefile
index 8a20c76..85c5e2d 100644
--- a/Makefile
+++ b/Makefile
@@ -96,6 +96,7 @@ bindir = $(prefix)/bin
gitexecdir = $(bindir)
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
+ZSH_COMPL_DIR = $(prefix)/share/zsh/site-functions
# DESTDIR=
CC = gcc
@@ -438,13 +439,14 @@ SHELL_PATH_SQ = $(subst ','\'',$(SHELL_P
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
PYTHON_PATH_SQ = $(subst ','\'',$(PYTHON_PATH))
GIT_PYTHON_DIR_SQ = $(subst ','\'',$(GIT_PYTHON_DIR))
+ZSH_COMPL_DIR_SQ = $(subst ','\'',$(ZSH_COMPL_DIR))
ALL_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' $(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(ALL_PROGRAMS) git$X gitk
+all: $(ALL_PROGRAMS) git$X gitk _git
all:
$(MAKE) -C templates
@@ -553,6 +555,8 @@ $(LIB_FILE): $(LIB_OBJS)
doc:
$(MAKE) -C Documentation all
+_git: generate-zsh-compl.sh
+ ./generate-zsh-compl.sh version help $(ALL_PROGRAMS) > _git
### Testing rules
@@ -586,6 +590,8 @@ install: all
$(MAKE) -C templates install
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
$(INSTALL) $(PYMODULES) '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
+ $(INSTALL) -d -m755 $(ZSH_COMPL_DIR)
+ $(INSTALL) -m644 _git '$(DESTDIR_SQ)$(ZSH_COMPL_DIR_SQ)'
install-doc:
$(MAKE) -C Documentation install
diff --git a/generate-zsh-compl.sh b/generate-zsh-compl.sh
new file mode 100755
index 0000000..f8c80de
--- /dev/null
+++ b/generate-zsh-compl.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+cmds=$(echo "$@" | sed s/git-//g | sed "s/\\.[^ ]*//g")
+
+cat <<EOF
+#compdef git
+
+# Automatically generated by $0
+
+local _git_subcommands expl curcontext="$curcontext"
+
+_arguments \
+ '--version' \
+ '--exec-path=:Git exec path:_path_files' \
+ '--help' \
+ '*::git command:->subcmd' && return 0
+
+ _git_subcommands=($cmds)
+
+if (( CURRENT == 1 )); then
+ _describe -t subcommand 'subcommand' _git_subcommands
+else
+ # this part should be tailored for subcmds
+ _files
+fi
+EOF
^ permalink raw reply related
* [PATCH] ls-files: Don't require exclude files to end with a newline.
From: Alexandre Julliard @ 2006-03-18 10:27 UTC (permalink / raw)
To: git
Without this patch, the last line of an exclude file is silently
ignored if it doesn't end with a newline.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
ls-files.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
9c5a78851bcf3b541364f818f6b397c29a8f4592
diff --git a/ls-files.c b/ls-files.c
index df25c8c..e42119c 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -92,11 +92,12 @@ static int add_excludes_from_file_1(cons
close(fd);
return 0;
}
- buf = xmalloc(size);
+ buf = xmalloc(size+1);
if (read(fd, buf, size) != size)
goto err;
close(fd);
+ buf[size++] = '\n';
entry = buf;
for (i = 0; i < size; i++) {
if (buf[i] == '\n') {
--
1.2.4.g5a1f-dirty
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH] git-merge: New options `--no-fast-forward' and `--direct'.
From: Mark Wooding @ 2006-03-18 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <slrne1nnhm.fr9.mdw@metalzone.distorted.org.uk>
From: Mark Wooding <mdw@distorted.org.uk>
These options disable some of git-merge's optimizations.
--no-fast-forward
Does what it says on the tin: git-merge will always make a
commit as a result of this merge (or leave one in the pipeline,
if --no-commit was given).
--direct
Don't do anything clever: go directly to the merge strategy
programs. In particular, this forbids an attempt at in-index
merging.
We also force direct merging with the `ours' strategy, since this is
obviously what was wanted.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
Documentation/merge-options.txt | 9 ++++++++-
git-merge.sh | 28 ++++++++++++++++++++++------
git-pull.sh | 13 +++++++++++--
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 53cc355..5b145a1 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -6,7 +6,6 @@
not autocommit, to give the user a chance to inspect and
further tweak the merge result before committing.
-
-s <strategy>, \--strategy=<strategy>::
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
@@ -14,3 +13,11 @@
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise).
+--no-ff, \--no-fast-forward::
+ Don't fast-forward, even when it looks possible. There will
+ always be a commit to do at the end of the merge.
+
+--direct::
+ Don't do anything clever: go directly to the merge strategy
+ programs. In particular, this forbids an attempt at in-index
+ merging.
diff --git a/git-merge.sh b/git-merge.sh
index cc0952a..d6a579f 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -13,6 +13,8 @@ LF='
all_strategies='recursive octopus resolve stupid ours'
default_strategies='recursive'
use_strategies=
+ff=t
+index_merge=t
if test "@@NO_PYTHON@@"; then
all_strategies='resolve octopus stupid ours'
default_strategies='resolve'
@@ -65,6 +67,12 @@ do
no_summary=t ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
no_commit=t ;;
+ --no-f|--no-ff|--no-fa|--no-fas|--no-fast|--no-fast-|--no-fast-f|\
+ --no-fast-fo|--no-fast-for|--no-fast-forw|--no-fast-forwa|\
+ --no-fast-forwar|--no-fast-forward)
+ ff=f ;;
+ --d|--di|--dir|--dire|--direc|--direct)
+ ff=f index_merge=f ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -90,6 +98,10 @@ do
shift
done
+# `ours' is a funny strategy and clever merging optimizations here make
+# it not work.
+case " $use_strategies " in *" ours "*) ff=f index_merge=f ;; esac
+
test "$#" -le 2 && usage ;# we need at least two heads.
merge_msg="$1"
@@ -118,18 +130,18 @@ case "$#" in
esac
echo "$head" >"$GIT_DIR/ORIG_HEAD"
-case "$#,$common,$no_commit" in
-*,'',*)
+case "$#,$ff,$index_merge,$common,$no_commit" in
+*,*,*,'',*)
# No common ancestors found. We need a real merge.
;;
-1,"$1",*)
+1,*,*,"$1",*)
# If head can reach all the merge then we are up to date.
# but first the most common case of merging one remote
echo "Already up-to-date."
dropsave
exit 0
;;
-1,"$head",*)
+1,t,*,"$head",*)
# Again the most common case of merging one remote.
echo "Updating from $head to $1"
git-update-index --refresh 2>/dev/null
@@ -139,11 +151,11 @@ case "$#,$common,$no_commit" in
dropsave
exit 0
;;
-1,?*"$LF"?*,*)
+1,*,*,?*"$LF"?*,*)
# We are not doing octopus and not fast forward. Need a
# real merge.
;;
-1,*,)
+1,*,t,*,)
# We are not doing octopus, not fast forward, and have only
# one common. See if it is really trivial.
git var GIT_COMMITTER_IDENT >/dev/null || exit
@@ -164,6 +176,10 @@ case "$#,$common,$no_commit" in
fi
echo "Nope."
;;
+1,*,*,*,)
+ # Only a single remote, but we've been told not to try anything
+ # clever. Skip to real merge.
+ ;;
*)
# An octopus. If we can reach all the remote we are up to date.
up_to_date=t
diff --git a/git-pull.sh b/git-pull.sh
index 17fda26..229cec7 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -8,7 +8,7 @@ USAGE='[-n | --no-summary] [--no-commit]
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
. git-sh-setup
-strategy_args= no_summary= no_commit=
+strategy_args= no_summary= no_commit= noff= direct=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
@@ -17,6 +17,12 @@ do
no_summary=-n ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
no_commit=--no-commit ;;
+ --no-f|--no-ff|--no-fa|--no-fas|--no-fast|--no-fast-|--no-fast-f|\
+ --no-fast-fo|--no-fast-for|--no-fast-forw|--no-fast-forwa|\
+ --no-fast-forwar|--no-fast-forward)
+ noff=--no-fast-forward ;;
+ --d|--di|--dir|--dire|--direc|--direct)
+ direct=--direct ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -92,4 +98,7 @@ case "$strategy_args" in
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
-git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
+git-merge \
+ $no_summary $no_commit $noff $direct \
+ $strategy_args \
+ "$merge_name" HEAD $merge_head
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox