* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Jeff King @ 2008-07-04 19:51 UTC (permalink / raw)
To: Adam Brewster; +Cc: git, Mark Levedahl, Junio C Hamano, Jakub Narebski
In-Reply-To: <c376da900807031638l219229bcy983ed994b37512c9@mail.gmail.com>
On Thu, Jul 03, 2008 at 07:38:21PM -0400, Adam Brewster wrote:
> There's still plenty of potential for improvements, like a --gc mode
> to clean up basis files, a --rewind option to undo an incorrect
> --update, or improvements in the way it calculates intersections, but
> I think that with these changes the system is as simple as possible
> while maximizing flexibility, utility, and usability.
I was thinking about Mark's approach, and I think there are two distinct
differences from yours:
1. he updates the basis upon bundle creation, rather than as a
separate step (and I have already commented on this)
2. he stores the basis in the refs hierarchy
I actually think '2' makes a lot of sense. Storing the basis as refs
gets you:
- an easy implementation; you use existing git tools
- correct reachability analysis, since the refs will be taken into
account by git-fsck, meaning you won't ever accidentally prune
your basis objects
- free logging of your basis history, in the form of reflogs
- free gc in the usual reflog way
IIRC, Mark suggested putting them under refs/remotes/<bundle>, and you
objected that you didn't want to clutter that hierarchy. If that is a
problem, you can always use refs/basis/<bundle>, which will be ignored
by gitk and "git branch -a", but will be correctly handled by other
tools.
And then suddenly your perl script gets a lot simpler, and is either a
short shell script, or even better, can be written in C as part of
git-bundle. So you would have something like "git bundle --update-basis
<basis>" instead of "git-basis", and a config option like
"bundle.autoUpdateBasis" to update the basis whenever you create a
bundle.
-Peff
^ permalink raw reply
* Re: [PATCH]: fix typos in docs
From: Junio C Hamano @ 2008-07-04 19:37 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: git
In-Reply-To: <877ic1sg47.fsf@offby1.atm01.sea.blarg.net>
Eric Hanchrow <offby1@blarg.net> writes:
> From 098e3ec480254069d944e494a42afcf2013d08d7 Mon Sep 17 00:00:00 2001
> From: Eric Hanchrow <offby1@blarg.net>
> Date: Mon, 30 Jun 2008 23:34:08 -0700
> Subject: [PATCH] Fix typos
Unnecessarily duplicated headers. Please drop them, especially the first
one (the latter three are fine if the difference between them and what
appears in your e-mail header matters).
> diff --git a/Documentation/.gitignore b/Documentation/.gitignore
> index d8edd90..ce24e4a 100644
> --- a/Documentation/.gitignore
> +++ b/Documentation/.gitignore
This part does not look like "fix typos" at all, and is an unrelated
change. Explain in the commit log message please.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> - then 'gitcvs.allbinary' is used. See linkgit:gitattribute[5].
> + then 'gitcvs.allbinary' is used. See linkgit:gitattributes[5].
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> -linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
> +linkgit:everyday[7], linkgit:gitcvs-migration[7],
> diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
> -linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
> +linkgit:everyday[7], linkgit:gitcvs-migration[7],
> diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt
> -linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
> +linkgit:everyday[7], linkgit:gitcvs-migration[7],
These are "fix broken links" aren't they? Please make them into a
separate patch that has only "fix broken links" and nothing else.
The remaining are rewording, "fix grammar", with one typofix; it is good
to include them in a single patch but please give a bit better label.
Please split this into at least two, possibly three patches:
(0) A change to Documentation/.gitignore with justification. As far as I
can see, the two files you added are not built products nor cruft
left by our build procedure.
(1) "Documentation: fix broken links".
(2) "Documentation: fix grammar and typo, and reword for readability".
^ permalink raw reply
* Re: [PATCH] Fix apply --recount handling of no-EOL line
From: Johannes Schindelin @ 2008-07-04 19:34 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1215198614-22148-1-git-send-email-trast@student.ethz.ch>
Hi,
On Fri, 4 Jul 2008, Thomas Rast wrote:
> If a patch modifies the last line of a file that previously had no
> terminating '\n', it looks like
>
> -old text
> \ No newline at end of file
> +new text
Oh!
> Hence, a '\' line does not signal the end of the hunk. This modifies
> 'git apply --recount' to take this into account.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
ACK!
Ciao,
Dscho
^ permalink raw reply
* Re: dumb protocol problems
From: Michael P. Soulier @ 2008-07-04 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq1dv51e.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On 04/07/08 Junio C Hamano said:
> That snapshot lacks this fix:
>
> 6eec46b (fix sha1_pack_index_name(), 2008-05-28)
Confirmed, it works now.
Thanks,
Mike
--
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: dumb protocol problems
From: Junio C Hamano @ 2008-07-04 19:10 UTC (permalink / raw)
To: git
In-Reply-To: <20080704190007.GU28001@tigger.digitaltorque.ca>
"Michael P. Soulier" <msoulier@digitaltorque.ca> writes:
> git --version
> git version 1.5.6.rc0
That snapshot lacks this fix:
6eec46b (fix sha1_pack_index_name(), 2008-05-28)
^ permalink raw reply
* [PATCH] Fix apply --recount handling of no-EOL line
From: Thomas Rast @ 2008-07-04 19:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
If a patch modifies the last line of a file that previously had no
terminating '\n', it looks like
-old text
\ No newline at end of file
+new text
Hence, a '\' line does not signal the end of the hunk. This modifies
'git apply --recount' to take this into account.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
This is just the straightforward fix. A more elaborate solution might
check if the previous line was a ' ' and '+', and if so, consider the
hunk terminated anyway.
- Thomas
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 194f03b..fb85a5b 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -931,7 +931,7 @@ static void recount_diff(char *line, int size, struct fragment *fragment)
newlines++;
continue;
case '\\':
- break;
+ continue;
case '@':
ret = size < 3 || prefixcmp(line, "@@ ");
break;
--
1.5.6.1.330.g2ff03
^ permalink raw reply related
* dumb protocol problems
From: Michael P. Soulier @ 2008-07-04 19:00 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]
I'm in a situation where sharing via http is my simplest method, although I
will migrate to use git-daemon in the near future.
I'm on CentOS 4.6, Apache works fine, the bare repository is viewable and
there's a info/refs file like there should be.
msoulier@espresso:~/temp$ cat /var/www/git/cqr.git/info/refs
0a27e2807d8d3c32aa8912d01c939bd1cdd0df68 refs/heads/master
But cloning fails.
git clone http://espresso.nssg.mitel.com/gitdir/cqr.git
Initialize cqr/.git
Initialized empty Git repository in /usr/home/msoulier/temp/cqr/.git/
Getting alternates list for http://espresso.nssg.mitel.com/gitdir/cqr.git
Getting pack list for http://espresso.nssg.mitel.com/gitdir/cqr.git
Getting index for pack d22362ff6cdd729015f787a7eae057e079fcee39
Getting pack d22362ff6cdd729015f787a7eae057e079fcee39
which contains 0a27e2807d8d3c32aa8912d01c939bd1cdd0df68
error: packfile
/usr/home/msoulier/temp/cqr/.git/objects/pack/pack-d22362ff6cdd729015f787a7eae057e079fcee39.pack
size changed
fatal: packfile
/usr/home/msoulier/temp/cqr/.git/objects/pack/pack-d22362ff6cdd729015f787a7eae057e079fcee39.pack
cannot be accessed
This is not on NFS, it's an LVM filesystem on a local disk.
msoulier@espresso:~/temp$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
36G 22G 13G 64% /
I'm not sure what the issue could be.
git --version
git version 1.5.6.rc0
I'll start by picking up the latest.
Thanks,
Mike
--
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-gui fails to start
From: Michael P. Soulier @ 2008-07-04 18:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080702045352.GM11793@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
On 02/07/08 Shawn O. Pearce said:
> I think this was fixed in gitgui-0.10.2, which did not ship with
> Git proper until 1.5.6-rc0. Now that 1.5.6.1 has been released I
> would encourage you to upgrade to the latest stable release of Git.
I'll try that, thanks.
Mike
--
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] t4127-apply-same-fn: Avoid sed -i
From: Johannes Schindelin @ 2008-07-04 18:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Don Zickus, git, Junio C Hamano
In-Reply-To: <486DC687.4070307@viscovery.net>
Hi,
On Fri, 4 Jul 2008, Johannes Sixt wrote:
> > When I created the tests for my git-apply patch, I accidently used the
> > '-i' flag for sed.
Maybe we should modify our hooks so that this is warned about? While at
it, we could warn about quoted "wc -l", too...
Ciao,
Dscho
^ permalink raw reply
* [PATCH]: fix typos in docs
From: Eric Hanchrow @ 2008-07-04 17:39 UTC (permalink / raw)
To: git
>From 098e3ec480254069d944e494a42afcf2013d08d7 Mon Sep 17 00:00:00 2001
From: Eric Hanchrow <offby1@blarg.net>
Date: Mon, 30 Jun 2008 23:34:08 -0700
Subject: [PATCH] Fix typos
---
Documentation/.gitignore | 10 ++++++----
Documentation/config.txt | 2 +-
Documentation/git.txt | 2 +-
Documentation/gitcore-tutorial.txt | 2 +-
Documentation/gitglossary.txt | 2 +-
Documentation/user-manual.txt | 18 +++++++++---------
6 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index d8edd90..ce24e4a 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1,10 +1,12 @@
-*.xml
-*.html
*.[1-8]
+*.html
*.made
*.texi
+*.xml
+cmds-*.txt
+doc.dep
+fancytooltips.js
+favicon.ico
git.info
gitman.info
howto-index.txt
-doc.dep
-cmds-*.txt
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 561ff64..e891745 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -680,7 +680,7 @@ gitcvs.usecrlfattr
treat it as text. If `crlf` is explicitly unset, the file
will be set with '-kb' mode, which supresses any newline munging
the client might otherwise do. If `crlf` is not specified,
- then 'gitcvs.allbinary' is used. See linkgit:gitattribute[5].
+ then 'gitcvs.allbinary' is used. See linkgit:gitattributes[5].
gitcvs.allbinary::
This is used if 'gitcvs.usecrlfattr' does not resolve
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 22702c2..fa67383 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -591,7 +591,7 @@ contributors on the git-list <git@vger.kernel.org>.
SEE ALSO
--------
linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+linkgit:everyday[7], linkgit:gitcvs-migration[7],
linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
linkgit:gitcli[7], link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 7d721c5..9195997 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1690,7 +1690,7 @@ to follow, not easier.
SEE ALSO
--------
linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+linkgit:everyday[7], linkgit:gitcvs-migration[7],
link:user-manual.html[The Git User's Manual]
GIT
diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt
index 5c5c31d..565719e 100644
--- a/Documentation/gitglossary.txt
+++ b/Documentation/gitglossary.txt
@@ -17,7 +17,7 @@ include::glossary-content.txt[]
SEE ALSO
--------
linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+linkgit:everyday[7], linkgit:gitcvs-migration[7],
link:user-manual.html[The Git User's Manual]
GIT
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ca13266..ae6525a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -518,7 +518,7 @@ $ git bisect visualize
-------------------------------------------------
which will run gitk and label the commit it chose with a marker that
-says "bisect". Chose a safe-looking commit nearby, note its commit
+says "bisect". Choose a safe-looking commit nearby, note its commit
id, and check it out with:
-------------------------------------------------
@@ -1988,8 +1988,8 @@ intend to manage the branch.
It's also possible for a push to fail in this way when other people have
the right to push to the same repository. In that case, the correct
-solution is to retry the push after first updating your work by either a
-pull or a fetch followed by a rebase; see the
+solution is to retry the push after first updating your work: either by a
+pull, or by a fetch followed by a rebase; see the
<<setting-up-a-shared-repository,next section>> and
linkgit:gitcvs-migration[7] for more.
@@ -2861,7 +2861,7 @@ There are four different types of objects: "blob", "tree", "commit", and
"tag".
- A <<def_blob_object,"blob" object>> is used to store file data.
-- A <<def_tree_object,"tree" object>> is an object that ties one or more
+- A <<def_tree_object,"tree" object>> ties one or more
"blob" objects into a directory structure. In addition, a tree object
can refer to other tree objects, thus creating a directory hierarchy.
- A <<def_commit_object,"commit" object>> ties such directory hierarchies
@@ -3036,7 +3036,7 @@ Tag Object
A tag object contains an object, object type, tag name, the name of the
person ("tagger") who created the tag, and a message, which may contain
-a signature, as can be seen using the linkgit:git-cat-file[1]:
+a signature, as can be seen using linkgit:git-cat-file[1]:
------------------------------------------------
$ git cat-file tag v1.5.0
@@ -3986,13 +3986,13 @@ $ mv -f hello.c~2 hello.c
$ git update-index hello.c
-------------------------------------------------
-When a path is in unmerged state, running `git-update-index` for
+When a path is in the "unmerged" state, running `git-update-index` for
that path tells git to mark the path resolved.
The above is the description of a git merge at the lowest level,
to help you understand what conceptually happens under the hood.
-In practice, nobody, not even git itself, uses three `git-cat-file`
-for this. There is `git-merge-index` program that extracts the
+In practice, nobody, not even git itself, runs `git-cat-file` three times
+for this. There is a `git-merge-index` program that extracts the
stages to temporary files and calls a "merge" script on it:
-------------------------------------------------
@@ -4061,7 +4061,7 @@ Note that terminology has changed since that revision. For example, the
README in that revision uses the word "changeset" to describe what we
now call a <<def_commit_object,commit>>.
-Also, we do not call it "cache" any more, but "index", however, the
+Also, we do not call it "cache" any more, but rather "index"; however, the
file is still called `cache.h`. Remark: Not much reason to change it now,
especially since there is no good single name for it anyway, because it is
basically _the_ header file which is included by _all_ of Git's C sources.
--
1.5.4.3
--
People studying literature rarely say anything that would be of the
slightest use to those producing it.
-- Paul Graham
^ permalink raw reply related
* Re: Puzzled by gitk patch representation for merge commits
From: Jonathan Nieder @ 2008-07-04 17:51 UTC (permalink / raw)
To: Jerome Lovy; +Cc: git
In-Reply-To: <g4kpmu$9ga$1@ger.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1026 bytes --]
Hi Jérôme,
Jerome Lovy wrote:
> I don't understand the graphical scheme that gitk uses when displaying
> patches for merge commits. I would like to be able to explain this to the
> people I'm trying to evangelize to git, because they are also puzzled when
> they try to check with gitk what a merge has done to a given file.
>
> I can see that at least three graphical hints seem to be involved:
> - font: regular/bold
> - color: red/blue
> (maybe there are more colors when the commit has more than two parents?)
> - column for displaying the '+' or '-'
All of the information is there in the text; the color and font are just
supposed to make it easier to see. As for the diff text itself, I
didn't remember what it meant myself, so I looked it up.
It seems the diff format shown is that produced by 'git-diff --cc',
which makes a "compact combined diff". It only shows conflicting
changes. Each column on the left represents the changes from a
different parent.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [Junio C Hamano] Re: Consolidate SHA1 object file close
From: Pierre Habouzit @ 2008-07-04 17:44 UTC (permalink / raw)
To: Junio C Hamano, Linus Torvalds; +Cc: git
In-Reply-To: <7viqwbfxk6.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 550 bytes --]
On Sat, Jun 14, 2008 at 10:42:33PM +0000, Junio C Hamano wrote:
> Somehow the thread went off-list, so I'm diverting it back to the list...
>
FWIW, the person with that patch here do not have the issue with NFS
at all, whereas people with older git versions have had the issue. IOW,
I consider my issue with NFS fixed by this patch.
Thanks a lot guys \o/
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Cherry picking instead of merges.
From: Linus Torvalds @ 2008-07-04 16:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: David Brown, Björn Steinbrink, git
In-Reply-To: <486DC4F2.70608@viscovery.net>
On Fri, 4 Jul 2008, Johannes Sixt wrote:
>
> FWIW, the same thing in different words is written in section
>
> "Why bisecting merge commits can be harder than bisecting linear history"
>
> of Documentation/user-manual.txt.
I don't think that's the same thign at all.
That section basically says "just keep things linear". Which I very much
disagree with. Trying to keep things linear just doesn't work if you work
together with other people - since you have to rewrite history.
So my argument was the exact _reverse_. Don't try to keep things linear,
because it doesn't _work_ right. Do the merges. They will very seldom
cause subtle merge problems (non-subtle ones are much more common, but
trivial to handle), and they will mean that you can work effectively
togethr with other people.
And then, _if_ you have a merge that you really cannot figure out why it
breaks, at that point you can _temporarily_ linearize the git history
after-the-fact just as easily as you would ever have done before-the-fact.
In other words: linearization throws away real and useful information. You
can always linearize afterwards for bisection purposes or whatever, but
you can never _un_linearize because you've thrown away the information.
So it's much better to just do merges and keep the history, and then there
are ways to rewrite the history later if you really need it.
That said - I think it's good practice and perfectly sane to do things
like git-rebase to rewrite the history in a _private_ tree that contains
only your own modifications and has never been public (where "applied
emailed patches from others" still counts as your own work).
The "don't linearize" mantra really only is about commits that have ever
been in anybody elses repository (and whether they _came_ from there, or
whether they came from you but were public to others is immaterial).
Linus
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Mark Levedahl @ 2008-07-04 16:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Adam Brewster, git, Junio C Hamano, Jakub Narebski
In-Reply-To: <alpine.DEB.1.00.0807040237580.2849@eeepc-johanness>
Johannes Schindelin wrote:
> I am not convinced. This sort of feature belongs into git-bundle. It
> certainly does not deserve being blessed by yet-another git-* command,
> when we are constantly being bashed for having _way_ too many _already_.
>
> Ciao,
> Dscho
>
>
Actually, I would like to see "normal" interface for git-bundle handled
by git-push, git-fetch, and git-remote. We fixed the retrieve side to
use git-fetch before first integration, but didn't understand the
semantics for creation well-enough to put into git-push. Right now, we
can do "git remote add bundle-nick <path-to-bundle>" and set up the remote.
We should have "git push bundle-nick" create the new bundle, updating
the basis refs kept somewhere in refs/* (possibly refs/remotes, possibly
refs/bundles?).
However, we need two helpers to maintain the basis refs, both I believe
should be sub-commands of git-remote:
- a "rewind" function to roll the refs back to a previous state because
the bundle didn't get applied, whatever. This is well supported by
reflogs, is "expire anything *newer* than time", and for convenience
should apply to all refs for the given remote so the user doesn't have
to invoke per branch on the remote. e.g., "git remote rewind bundle-nick
3.days.ago".
- a "prune" function to remove any branch for the remote that is not
known to the local refs/heads/* hierarchy. This is needed to support
cleaning up pruned topic branches. Could be a special behavior of "git
remote prune" triggered by the remote being a bundle, but that might be
confusing a perhaps need a new sub-command name. Perhaps, "git remote
prune-non-local bundle-nick"
If we did the above, then git-bundle can be relegated to plumbing and
bundles become better integrated to the porcelain.
Mark
^ permalink raw reply
* Re: [PATCH] Allow cherry-picking root commits
From: Stephan Beyer @ 2008-07-04 16:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, git, Daniel Barkalow, Christian Couder
In-Reply-To: <alpine.DEB.1.00.0807041617320.9925@racer>
On Fri, Jul 04, 2008 at 04:19:52PM +0100, Johannes Schindelin wrote:
> Anyhow, I give up on trying to convince you.
Great :)
Big thanks for the patch!
It also works with my rebase-i variant with just an unimportant "fatal"
which can be shut up by
--- a/git-sequencer.sh
+++ b/git-sequencer.sh
@@ -211,7 +211,7 @@ pick_one () {
;;
cherry-pick,*)
# fast forward
- if test "$(git rev-parse --verify "$1^")" = \
+ if test "$(git rev-parse --verify "$1^" 2>/dev/null)" = \
"$(git rev-parse --verify HEAD)"
then
perform git reset --hard "$1"
###
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 04/15] Add new test to ensure git-merge handles pull.twohead and pull.octopus
From: Mike Ralphson @ 2008-07-04 16:34 UTC (permalink / raw)
To: Miklos Vajna, Junio C Hamano; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <99b931de28ab3017269d15c334c83e242d025489.1214581610.git.vmiklos@frugalware.org>
2008/6/27 Miklos Vajna <vmiklos@frugalware.org>:
>
> Test if the given strategies are used and test the case when multiple
> strategies are configured using a space separated list.
>
> Also test if the best strategy is picked if none is specified. This is
> done by adding a simple test case where recursive detects a rename, but
> resolve does not, and verify that finally merge will pick up the
> previous.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
> t/t7601-merge-pull-config.sh | 129 ++++++++++++++++++++++++++++++++++++++++++
> +
> +conflict_count()
> +{
> + eval $1=`{
> + git diff-files --name-only
> + git ls-files --unmerged
> + } | wc -l`
> +}
> +
This here causes the test to fail on AIX (and likely other OS, such as
apparently OSX) where wc -l outputs whitespace. See
http://article.gmane.org/gmane.comp.version-control.git/80450
Here we want the line count not just a return value, so is the
following acceptable?
diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
index 32585f8..9b6097d 100755
--- a/t/t7601-merge-pull-config.sh
+++ b/t/t7601-merge-pull-config.sh
@@ -73,7 +73,7 @@ conflict_count()
eval $1=`{
git diff-files --name-only
git ls-files --unmerged
- } | wc -l`
+ } | wc -l | tr -d \ `
}
# c4 - c5
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Anyway, I thought we preferred $() to backticks?
I do apologise for not being around for the earlier comedy breakage on
AIX, my sysadmins decided to 'improve' our firewall rules which cut my
automated builds off just after the final rc for 1.5.6, then I was on
vacation miles from any computers.
Mike
^ permalink raw reply related
* Re: [PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)
From: Clifford Caoile @ 2008-07-04 16:09 UTC (permalink / raw)
To: prohaska; +Cc: Junio C Hamano, johannes.sixt, msysGit, git, Edward Z. Yang
In-Reply-To: <7188A895-D5B9-480E-8486-8A69B8861646@zib.de>
Hi:
On Fri, Jul 4, 2008 at 6:29 PM, Steffen Prohaska <prohaska@zib.de> wrote:
>
> On Jul 4, 2008, at 11:18 AM, Junio C Hamano wrote:
>
>> Johannes Sixt <johannes.sixt@telecom.at> writes:
>>
>>> What about installing a wrapper script, plinkssh, that does this:
>>
>> That's quite a nice solution with absolute minimum impact.
>
> It has minimum impact on the source code of git. The same is not
> true, however, for the git user and the installer on Windows:
>
> - The proposed plinkssh requires that plink is in the PATH. This is
> not necessarily the case on Windows. If plink is not in the PATH,
> then the user needs to modify plinkssh.
>
> - The msysgit installer supports setting GIT_SSH to the full path
> of plink. It automatically detects this path based on Putty's
> entries in the Windows registry. If we choose the plinkssh
> solution the installer has to be modified.
How about we create one more global environment variable
MSYSGIT_REAL_PLINK which points to the Windows plink during
installation? Then we set the GIT_SSH to the plinkssh, and the
proposed plinkssh can point to MSYSGIT_REAL_PLINK?
+ # fall back to plink if MSYSGIT_REAL_PLINK is not defined
+ # and hope plink is in the path
+ plink=${MSYSGIT_REAL_PLINK:-plink}
- exec plink $port "$@"
+ exec ${plink} $port "$@"
Perhaps I have traded one problem for another, because the msysgit
user still has to be aware of MSYSGIT_REAL_PLINK (at least she doesn't
have to set it up). And of course, the installer has to be modified to
accommodate plinkssh and my proposal.
Best regards,
Clifford Caoile
^ permalink raw reply
* Re: no --dry-run to git-pull ?
From: Miklos Vajna @ 2008-07-04 15:29 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0807040826v64afcc55i646d9c73b6fa8cd0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
On Fri, Jul 04, 2008 at 06:26:02PM +0300, Neshama Parhoti <pneshama@gmail.com> wrote:
> > 1) Replace origin and master with your remote and branch.
> >
> > 2) If this sounds cryptic for you, then it might be an important info
> > that by default a pull is a fetch + a merge.
>
> What puzzles me is the origin keyword. Is it set only if I initially
> cloned a repo ?
> Because in my case, I have just rsync'ed a repo to another station, so
> I fear it will have no meaning in my case.
Heh. git remote add -f origin <url>, then you'll have it. And yes, you
have it if you cloned the repo, of course rsync won't add it. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: no --dry-run to git-pull ?
From: Neshama Parhoti @ 2008-07-04 15:26 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080704135944.GA4729@genesis.frugalware.org>
On Fri, Jul 4, 2008 at 4:59 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Fri, Jul 04, 2008 at 04:56:27PM +0300, Neshama Parhoti <pneshama@gmail.com> wrote:
>> Isn't there a way to do a --dry-run with git-pull ?
>
> Not really. But you can do a 'git fetch origin', then a
> 'git log master..origin/master', and it'll tell you what changes will be
> merged if you do a 'git merge origin/master'.
>
> NOTES:
>
> 1) Replace origin and master with your repomte and branch.
>
> 2) If this sounds cryptic for you, then it might be an important info
> that by default a pull is a fetch + a merge.
What puzzles me is the origin keyword. Is it set only if I initially
cloned a repo ?
Because in my case, I have just rsync'ed a repo to another station, so
I fear it will have no meaning in my case.
Thank you
>
^ permalink raw reply
* [PATCH] Allow cherry-picking root commits
From: Johannes Schindelin @ 2008-07-04 15:19 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, git, Daniel Barkalow, Christian Couder
In-Reply-To: <20080704015326.GI6677@leksak.fem-net>
There is no good reason why cherry-picking root commits should not be
allowed.
Further, since cherry-pick is the working horse of git-rebase, we _should_
allow picking root commits, so that you can rebase originally independent
branches on top of another branch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 4 Jul 2008, Stephan Beyer wrote:
> On Fri, Jul 04, 2008 at 03:03:37AM +0200, Johannes Schindelin
> wrote:
>
> > Well, logically, it should come _before_ you use it in
> > sequencer. And you should use it in sequencer.
>
> Yet nobody seems to have asked for a cherry-pick that is able to
> pick root commits and sequencer is not closed source after GSoC, so
> this can be added whenever there is need and time for it.
However, this is the wrong sequence.
Anyhow, I give up on trying to convince you.
builtin-revert.c | 26 ++++++++++++++++----------
t/t3503-cherry-pick-root.sh | 30 ++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 10 deletions(-)
create mode 100755 t/t3503-cherry-pick-root.sh
diff --git a/builtin-revert.c b/builtin-revert.c
index 0270f9b..f3d4524 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -206,6 +206,7 @@ static int merge_recursive(const char *base_sha1,
{
char buffer[256];
const char *argv[6];
+ int i = 0;
sprintf(buffer, "GITHEAD_%s", head_sha1);
setenv(buffer, head_name, 1);
@@ -218,12 +219,13 @@ static int merge_recursive(const char *base_sha1,
* and $prev on top of us (when reverting), or the change between
* $prev and $commit on top of us (when cherry-picking or replaying).
*/
- argv[0] = "merge-recursive";
- argv[1] = base_sha1;
- argv[2] = "--";
- argv[3] = head_sha1;
- argv[4] = next_sha1;
- argv[5] = NULL;
+ argv[i++] = "merge-recursive";
+ if (base_sha1)
+ argv[i++] = base_sha1;
+ argv[i++] = "--";
+ argv[i++] = head_sha1;
+ argv[i++] = next_sha1;
+ argv[i++] = NULL;
return run_command_v_opt(argv, RUN_COMMAND_NO_STDIN | RUN_GIT_CMD);
}
@@ -297,9 +299,12 @@ static int revert_or_cherry_pick(int argc, const char **argv)
discard_cache();
}
- if (!commit->parents)
- die ("Cannot %s a root commit", me);
- if (commit->parents->next) {
+ if (!commit->parents) {
+ if (action == REVERT)
+ die ("Cannot revert a root commit");
+ parent = NULL;
+ }
+ else if (commit->parents->next) {
/* Reverting or cherry-picking a merge commit */
int cnt;
struct commit_list *p;
@@ -368,7 +373,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
}
}
- if (merge_recursive(sha1_to_hex(base->object.sha1),
+ if (merge_recursive(base == NULL ?
+ NULL : sha1_to_hex(base->object.sha1),
sha1_to_hex(head), "HEAD",
sha1_to_hex(next->object.sha1), oneline) ||
write_cache_as_tree(head, 0, NULL)) {
diff --git a/t/t3503-cherry-pick-root.sh b/t/t3503-cherry-pick-root.sh
new file mode 100755
index 0000000..b0faa29
--- /dev/null
+++ b/t/t3503-cherry-pick-root.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+test_description='test cherry-picking a root commit'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo first > file1 &&
+ git add file1 &&
+ test_tick &&
+ git commit -m "first" &&
+
+ git symbolic-ref HEAD refs/heads/second &&
+ rm .git/index file1 &&
+ echo second > file2 &&
+ git add file2 &&
+ test_tick &&
+ git commit -m "second"
+
+'
+
+test_expect_success 'cherry-pick a root commit' '
+
+ git cherry-pick master &&
+ test first = $(cat file1)
+
+'
+
+test_done
--
1.5.6.1.376.g6b0fd
^ permalink raw reply related
* Re: no --dry-run to git-pull ?
From: Miklos Vajna @ 2008-07-04 13:59 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0807040656y1c48cba8m6f9981f6bb97b36a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Fri, Jul 04, 2008 at 04:56:27PM +0300, Neshama Parhoti <pneshama@gmail.com> wrote:
> Isn't there a way to do a --dry-run with git-pull ?
Not really. But you can do a 'git fetch origin', then a
'git log master..origin/master', and it'll tell you what changes will be
merged if you do a 'git merge origin/master'.
NOTES:
1) Replace origin and master with your repomte and branch.
2) If this sounds cryptic for you, then it might be an important info
that by default a pull is a fetch + a merge.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* no --dry-run to git-pull ?
From: Neshama Parhoti @ 2008-07-04 13:56 UTC (permalink / raw)
To: git
Hi,
Isn't there a way to do a --dry-run with git-pull ?
Thank you,
pnesh
^ permalink raw reply
* Re: can't push to ransom ssh port ?
From: Neshama Parhoti @ 2008-07-04 13:55 UTC (permalink / raw)
To: Vaclav Hanzl; +Cc: git
In-Reply-To: <20080704.153555.71091133.hanzl@noel.feld.cvut.cz>
Thanks.
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Mark Levedahl @ 2008-07-04 13:49 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Mark Levedahl, Adam Brewster, Junio C Hamano, git, Jakub Narebski
In-Reply-To: <alpine.DEB.1.00.0807041420330.9925@racer>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 4 Jul 2008, Mark Levedahl wrote:
>
>
> /me wonders if it would not make sense to support "git push <bundle>",
> then. Maybe with a running counter, i.e.
>
> $ git push the-bundle-5.bundle master
>
> would create the-bundle-6.bundle with everything needed in addition to
> the-bundle-5.bundle to have the current "master".
>
> Just an idea,
> Dscho
>
I think the trouble here is that the-bundle-5.bundle does not necessarily
contain the basis. Consider the general case of pushing master, next, pu, and
only pu has updated since the last push. Now, the-bundle-6.bundle will only
contain pu, not master nor next as there is nothing new, and thus is not a good
basis for creating the-bundle-7.bundle. This leads to a need for a meta-storage
of basis or a redefinition of how git-bundle deals with refs that are equal to
the given basis (currently, it excludes such refs).
Mark
^ permalink raw reply
* Re: can't push to ransom ssh port ?
From: Vaclav Hanzl @ 2008-07-04 13:35 UTC (permalink / raw)
To: pneshama; +Cc: git
In-Reply-To: <912ec82a0807040628k14c8acd1ree9d82b68f69e080@mail.gmail.com>
> Is there a way to tell git to connect to a random port X ?
>
> (something like ssh's -p parameter)
It can also be done using ~/.ssh/config with this:
Host a.b.c.d
Port 12345
(see man ssh_config), this way you just need to do it at one place for
ssh, scp and all git repositories.
Regards
Vaclav
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox