* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Stephan Beyer @ 2008-10-29 1:01 UTC (permalink / raw)
To: Jeff King; +Cc: David Symonds, git, gitster
In-Reply-To: <20081029003931.GA7291@sigill.intra.peff.net>
Hi,
> > --- /dev/null
> > +++ b/git-staged.sh
> > @@ -0,0 +1,2 @@
> > +#!/bin/sh
> > +exec git diff --cached $*
>
> This is broken for arguments with spaces. Use "$@" instead.
>
> But I think this isn't a serious patch anyway, so we are probably
> wasting too much time on it. ;P
I'm still not understanding, what it's for.
Usability? Because doing
git config --global alias.staged 'diff --cached'
is lame?
Regards,
Stephan
PS: Btw, if ever meant serious, it's missing an insertion into
command-list.txt and serious documentation.
But I think you know that. :-)
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Jeff King @ 2008-10-29 0:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Symonds, git, gitster
In-Reply-To: <alpine.DEB.1.00.0810290201400.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Wed, Oct 29, 2008 at 02:02:29AM +0100, Johannes Schindelin wrote:
> > +git-staged
>
> Would it not be better to teach "git show --staged" to do that, and to add
> a command pair "git stage <file>" and "git unstage <file>" to do the
> obvious?
Yes, I think half of the discussion went on IRC. But I don't think "git
staged" is a good idea. I think a "--staged" alias for "--cached" in
"git diff" makes a lot more sense.
-Peff
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Johannes Schindelin @ 2008-10-29 1:02 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster, Jeff King
In-Reply-To: <1225241048-99267-1-git-send-email-dsymonds@gmail.com>
Hi,
On Tue, 28 Oct 2008, David Symonds wrote:
> diff --git a/.gitignore b/.gitignore
> index bbaf9de..9353d19 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -118,6 +118,7 @@ git-show
> git-show-branch
> git-show-index
> git-show-ref
> +git-staged
Would it not be better to teach "git show --staged" to do that, and to add
a command pair "git stage <file>" and "git unstage <file>" to do the
obvious?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: David Symonds @ 2008-10-29 0:44 UTC (permalink / raw)
To: git, gitster, Jeff King; +Cc: David Symonds
In-Reply-To: <20081029003931.GA7291@sigill.intra.peff.net>
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
.gitignore | 1 +
Makefile | 1 +
git-staged.sh | 2 ++
3 files changed, 4 insertions(+), 0 deletions(-)
create mode 100755 git-staged.sh
diff --git a/.gitignore b/.gitignore
index bbaf9de..9353d19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -118,6 +118,7 @@ git-show
git-show-branch
git-show-index
git-show-ref
+git-staged
git-stash
git-status
git-stripspace
diff --git a/Makefile b/Makefile
index d6f3695..1b23e53 100644
--- a/Makefile
+++ b/Makefile
@@ -262,6 +262,7 @@ SCRIPT_SH += git-rebase.sh
SCRIPT_SH += git-repack.sh
SCRIPT_SH += git-request-pull.sh
SCRIPT_SH += git-sh-setup.sh
+SCRIPT_SH += git-staged.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
diff --git a/git-staged.sh b/git-staged.sh
new file mode 100755
index 0000000..66a5e33
--- /dev/null
+++ b/git-staged.sh
@@ -0,0 +1,2 @@
+#!/bin/sh
+exec git diff --cached "$@"
--
1.6.0
^ permalink raw reply related
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Jeff King @ 2008-10-29 0:39 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster
In-Reply-To: <1225238368-98594-1-git-send-email-dsymonds@gmail.com>
On Tue, Oct 28, 2008 at 04:59:28PM -0700, David Symonds wrote:
> --- /dev/null
> +++ b/git-staged.sh
> @@ -0,0 +1,2 @@
> +#!/bin/sh
> +exec git diff --cached $*
This is broken for arguments with spaces. Use "$@" instead.
But I think this isn't a serious patch anyway, so we are probably
wasting too much time on it. ;P
-Peff
^ permalink raw reply
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Johannes Schindelin @ 2008-10-29 0:46 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83ej20cndw.fsf@kalahari.s2.org>
Hi,
On Wed, 29 Oct 2008, Hannu Koivisto wrote:
> Hannu Koivisto <azure@iki.fi> writes:
>
> > "Christian Couder" <christian.couder@gmail.com> writes:
> >
> >> On Tue, Oct 28, 2008 at 6:51 PM, Hannu Koivisto <azure@iki.fi> wrote:
> >>> "Christian Couder" <christian.couder@gmail.com> writes:
> >
> >> We need at least a way to detect we are under Cygwin, because we
> >> won't change the current behavior for all platforms. Is checking for
> >> the CYGWIN environment variable enough?
> >
> > No, because it may not be set. I would probably do it at compile time
> > using __CYGWIN__ definition. I don't know what's the status
>
> Argh, I didn't realize git-bisect is a shell script. For detecting
> Cygwin in shell scripts I have tested if `uname` matches CYGWIN*. For
> detecting Windows I have tested if PROCESSOR_ARCHITECTURE is set.
> There may well be better ways.
I submitted a patch a while ago, saying
bisect view: call gitk if Cygwin's SESSIONNAME variable is set
See
http://repo.or.cz/w/git/dscho.git?a=commitdiff;h=a2637a3a003646c69ab5a6b85f0ee1bfac15e0b0
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git branch -m: forbid renaming of a symref
From: Miklos Vajna @ 2008-10-29 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <20081028234541.GY24201@genesis.frugalware.org>
There may be cases where one would really want to rename the symbolic
ref without changing its value, but "git branch -m" is not such a
use-case.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
This applies on top of 'mv/maint-branch-m-symref'.
refs.c | 29 +++++++++++++----------------
t/t3200-branch.sh | 8 ++++----
2 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/refs.c b/refs.c
index b39e6f2..8a38e08 100644
--- a/refs.c
+++ b/refs.c
@@ -964,14 +964,14 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
struct stat loginfo;
int log = !lstat(git_path("logs/%s", oldref), &loginfo);
const char *symref = NULL;
- int is_symref = 0;
if (log && S_ISLNK(loginfo.st_mode))
return error("reflog for %s is a symlink", oldref);
symref = resolve_ref(oldref, orig_sha1, 1, &flag);
if (flag & REF_ISSYMREF)
- is_symref = 1;
+ return error("refname %s is a symbolic ref, renaming it is not supported",
+ oldref);
if (!symref)
return error("refname %s not found", oldref);
@@ -1035,20 +1035,17 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
}
logmoved = log;
- if (!is_symref) {
- lock = lock_ref_sha1_basic(newref, NULL, 0, NULL);
- if (!lock) {
- error("unable to lock %s for update", newref);
- goto rollback;
- }
- lock->force_write = 1;
- hashcpy(lock->old_sha1, orig_sha1);
- if (write_ref_sha1(lock, orig_sha1, logmsg)) {
- error("unable to write current sha1 into %s", newref);
- goto rollback;
- }
- } else
- create_symref(newref, symref, logmsg);
+ lock = lock_ref_sha1_basic(newref, NULL, 0, NULL);
+ if (!lock) {
+ error("unable to lock %s for update", newref);
+ goto rollback;
+ }
+ lock->force_write = 1;
+ hashcpy(lock->old_sha1, orig_sha1);
+ if (write_ref_sha1(lock, orig_sha1, logmsg)) {
+ error("unable to write current sha1 into %s", newref);
+ goto rollback;
+ }
return 0;
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index fdeb1f5..25e9971 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -112,13 +112,13 @@ test_expect_success 'config information was renamed, too' \
"test $(git config branch.s.dummy) = Hello &&
test_must_fail git config branch.s/s/dummy"
-test_expect_success 'renaming a symref' \
+test_expect_success 'renaming a symref is not allowed' \
'
git symbolic-ref refs/heads/master2 refs/heads/master &&
- git branch -m master2 master3 &&
- git symbolic-ref refs/heads/master3 &&
+ test_must_fail git branch -m master2 master3 &&
+ git symbolic-ref refs/heads/master2 &&
test -f .git/refs/heads/master &&
- ! test -f .git/refs/heads/master2
+ ! test -f .git/refs/heads/master3
'
test_expect_success \
--
1.6.0.2
^ permalink raw reply related
* [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: David Symonds @ 2008-10-28 23:59 UTC (permalink / raw)
To: git, gitster, Jeff King; +Cc: David Symonds
In-Reply-To: <1225237145-95435-1-git-send-email-dsymonds@gmail.com>
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
.gitignore | 1 +
Makefile | 1 +
git-staged.sh | 2 ++
3 files changed, 4 insertions(+), 0 deletions(-)
create mode 100755 git-staged.sh
diff --git a/.gitignore b/.gitignore
index bbaf9de..9353d19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -118,6 +118,7 @@ git-show
git-show-branch
git-show-index
git-show-ref
+git-staged
git-stash
git-status
git-stripspace
diff --git a/Makefile b/Makefile
index d6f3695..1b23e53 100644
--- a/Makefile
+++ b/Makefile
@@ -262,6 +262,7 @@ SCRIPT_SH += git-rebase.sh
SCRIPT_SH += git-repack.sh
SCRIPT_SH += git-request-pull.sh
SCRIPT_SH += git-sh-setup.sh
+SCRIPT_SH += git-staged.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
diff --git a/git-staged.sh b/git-staged.sh
new file mode 100755
index 0000000..85582ec
--- /dev/null
+++ b/git-staged.sh
@@ -0,0 +1,2 @@
+#!/bin/sh
+exec git diff --cached $*
--
1.6.0
^ permalink raw reply related
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Jeff King @ 2008-10-28 23:46 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster
In-Reply-To: <1225237145-95435-1-git-send-email-dsymonds@gmail.com>
On Tue, Oct 28, 2008 at 04:39:05PM -0700, David Symonds wrote:
> --- /dev/null
> +++ b/git-staged.sh
> @@ -0,0 +1,8 @@
> +#!/bin/sh
> +
> +USAGE=''
> +SUBDIRECTORY_OK='Yes'
> +OPTIONS_SPEC=
> +. git-sh-setup
> +
> +git diff --cached
Do you even need to do sh-setup? How about
#!/bin/sh
exec git diff --cached "$@"
-Peff
^ permalink raw reply
* Re: [PATCH 0/3] symref rename/delete fixes
From: Miklos Vajna @ 2008-10-28 23:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1225136865.git.vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
On Mon, Oct 27, 2008 at 08:50:19PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Here they are. The first is updated: the delete_ref() part is unchanged,
> but the rename_ref() part is dropped and it just bails out with an error
> if it detects a symref. The testcase is updated according to this as
> well.
>
> The two others are just rebased on top of the new first one, no
> functional changes.
I forgot to fetch and did not notice the previous round is already in
'next'. Just forget about these patches then, I'll rebase the relevant
part against mv/maint-branch-m-symref and resend.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: David Symonds @ 2008-10-28 23:39 UTC (permalink / raw)
To: git, gitster; +Cc: David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
This isn't a particularly serious patch, but is very relevant to our
current discussion at GitTogether '08.
.gitignore | 1 +
Makefile | 1 +
git-staged.sh | 8 ++++++++
3 files changed, 10 insertions(+), 0 deletions(-)
create mode 100755 git-staged.sh
diff --git a/.gitignore b/.gitignore
index bbaf9de..9353d19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -118,6 +118,7 @@ git-show
git-show-branch
git-show-index
git-show-ref
+git-staged
git-stash
git-status
git-stripspace
diff --git a/Makefile b/Makefile
index d6f3695..1b23e53 100644
--- a/Makefile
+++ b/Makefile
@@ -262,6 +262,7 @@ SCRIPT_SH += git-rebase.sh
SCRIPT_SH += git-repack.sh
SCRIPT_SH += git-request-pull.sh
SCRIPT_SH += git-sh-setup.sh
+SCRIPT_SH += git-staged.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
diff --git a/git-staged.sh b/git-staged.sh
new file mode 100755
index 0000000..bfd36e7
--- /dev/null
+++ b/git-staged.sh
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+USAGE=''
+SUBDIRECTORY_OK='Yes'
+OPTIONS_SPEC=
+. git-sh-setup
+
+git diff --cached
--
1.6.0
^ permalink raw reply related
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Miklos Vajna @ 2008-10-28 23:28 UTC (permalink / raw)
To: Theodore Tso; +Cc: Pieter de Bie, Peter Krefting, Git Mailing List
In-Reply-To: <20081028213144.GC10862@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
On Tue, Oct 28, 2008 at 05:31:44PM -0400, Theodore Tso <tytso@mit.edu> wrote:
> The code I was referring to was called hg-fast-export, which is part
> of the "fast export" tools that front-end into git fast-import. The
> git repository can be found here:
>
> http://repo.or.cz/w/fast-export.git
> git://repo.or.cz/fast-export.git
>
> I ended up using a very customized version of that script to convert
> the hg e2fsprogs repository to git.
My bad, I did not quote the article properly, so here is what I meant:
http://article.gmane.org/gmane.comp.version-control.git/42298
and I just wanted to say that this one does not use fast-import, so it's
not really a "hg-fast-import" (it's not something that can parse the
output of git-fast-export).
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Hannu Koivisto @ 2008-10-28 23:26 UTC (permalink / raw)
To: git
In-Reply-To: <83iqrccpmk.fsf@kalahari.s2.org>
Hannu Koivisto <azure@iki.fi> writes:
> "Christian Couder" <christian.couder@gmail.com> writes:
>
>> On Tue, Oct 28, 2008 at 6:51 PM, Hannu Koivisto <azure@iki.fi> wrote:
>>> "Christian Couder" <christian.couder@gmail.com> writes:
>
>> We need at least a way to detect we are under Cygwin, because we won't
>> change the current behavior for all platforms.
>> Is checking for the CYGWIN environment variable enough?
>
> No, because it may not be set. I would probably do it at compile
> time using __CYGWIN__ definition. I don't know what's the status
Argh, I didn't realize git-bisect is a shell script. For detecting
Cygwin in shell scripts I have tested if `uname` matches CYGWIN*.
For detecting Windows I have tested if PROCESSOR_ARCHITECTURE is
set. There may well be better ways.
--
Hannu
^ permalink raw reply
* Any way to amend AuthorDate?
From: Jing Xue @ 2008-10-28 20:06 UTC (permalink / raw)
To: git
Is there any way to amend a commit and change only the Author Date?
For instance, I have a binary file that's been checked in in two
consecutive commits. After squashing them into one, the new commit would
keep the timestamp of the earlier one of the two original commits. I
would like it to have either the later timestamp or whenever the squash
happens.
Thanks for any pointers.
--
Jing Xue
^ permalink raw reply
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Hannu Koivisto @ 2008-10-28 22:37 UTC (permalink / raw)
To: git
In-Reply-To: <c07716ae0810281213k432d82d8i468f54ae03146b88@mail.gmail.com>
"Christian Couder" <christian.couder@gmail.com> writes:
> On Tue, Oct 28, 2008 at 6:51 PM, Hannu Koivisto <azure@iki.fi> wrote:
>> "Christian Couder" <christian.couder@gmail.com> writes:
> We need at least a way to detect we are under Cygwin, because we won't
> change the current behavior for all platforms.
> Is checking for the CYGWIN environment variable enough?
No, because it may not be set. I would probably do it at compile
time using __CYGWIN__ definition. I don't know what's the status
of merging MSysGit with "official" git but I suppose that when that
happens, __MING32__ and/or _WIN32 or something would need to be
considered as well.
>>> You can use "git bisect view log" to use "git log" even if DISPLAY is set.
>>
>> I'd rather not use undocumented functionality ;)
>
> In this case you can use any "git log" option after "git bisect view"
> (for example: git bisect view -p).
I was implying that "log" after "git bisect view" is not documented
by git-bisect(1). "log" is not a "git log" option.
--
Hannu
^ permalink raw reply
* Re: [StGit PATCH] Tutorial: Importing patches
From: Catalin Marinas @ 2008-10-28 22:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081028204223.9539.89315.stgit@yoghurt>
Hi Karl,
Thanks for the patch.
2008/10/28 Karl Hasselström <kha@treskal.com>:
> +Importing a patch from an e-mail is simple too:
> +
> + $ stg import --mail my-mail
> +
> +The e-mail should be in standard Git mail format (which is what e.g.
> +stglink:mail[] produces) -- that is, with the patch in-line in the
> +mail, not attached. The authorship info is taken from the mail
> +headers, and the commit message is read from the 'Subject:' line and
> +the mail body.
It actually supports importing diffs from attachments as well as long
as they are text/plain (the description is expected in the mail body).
Anyway, I think we don't have to mention this in the tutorial as most
people would use the Git mail format anyway.
--
Catalin
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Theodore Tso @ 2008-10-28 21:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Pieter de Bie, Peter Krefting, Git Mailing List
In-Reply-To: <20081028191234.GS24201@genesis.frugalware.org>
On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna wrote:
> On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> > fast-import yet. If I understand dscho correctly, that exists now, so it
> > should be easy enough to integrate that as well.
>
> That's new to me. Theodore Ts'o once mentioned on this list that there
> is a "hg fast-export" but actually he just referred to "there is a
> git2hg conversion tool in hg's contrib dir" and it has nothing with
> fast-import.
The code I was referring to was called hg-fast-export, which is part
of the "fast export" tools that front-end into git fast-import. The
git repository can be found here:
http://repo.or.cz/w/fast-export.git
git://repo.or.cz/fast-export.git
I ended up using a very customized version of that script to convert
the hg e2fsprogs repository to git.
In the past I've looked at the possibility of creating a
bi-directional, incremental gateway between hg and git repositories.
The main thing which makes this difficult is that hg stores tags
in-band inside the change-controlled .hgtags file. This means that if
you cut a release, tag it, and then create a commit to further modify
the repository, the new commit is descended from the tag commit,
whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
but not part of the revision history.
I think the git method is much more sane, but what it means is that
topologically, the commit tree for git and hg can never be identical.
It also means that if you add a tag to a git tree after making several
commits on that branch, how you reflect that in the hg repository is
highly problematic. Do you rewrite the branch? Do you add the tag
later on, disturbing the parent-child relationship of later commits?
How do you keep track of when a tag hg repository topology if you are
trying to maintain a bidirectional mapping between commits?
It's not impossible, but it makes it much more difficult, since in the
hg world, tag commits can be inserted between arbitrary commits. This
also means that if you want to create a bidrectional gateway between
hg and git, it has to be a single gateway so it can keep track of this
state information. If you try to have multiple gateways they would
need to synchronize on when a tag entered the hg universe, and with
what commit ID (and what timestamp).
- Ted
^ permalink raw reply
* Re: error pushing stash ?
From: Jeff King @ 2008-10-28 21:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Bryson, git
In-Reply-To: <20081028211755.GA8074@sigill.intra.peff.net>
On Tue, Oct 28, 2008 at 05:17:55PM -0400, Jeff King wrote:
> Since no version of receive-pack accepts these "funny refs", perhaps we
> should mirror the check when considering the list of refs to send. IOW,
> don't even make them eligible for matching or mirroring. Patch is below.
> [...]
> + /* we already know it starts with refs/ to get here */
> + if (check_ref_format(refname + 5))
> + return 0;
It occurs to me that since I didn't give a good commit message, and
since I replied to a several-weeks-old message, this might be confusing.
But what I am suggesting is that git-push should not bother trying to
send something that it knows git-receive-pack will refuse. So this check
goes into builtin-send-pack.c, and is an exact mirror of the one in
builtin-receive-pack.c:
$ sed -n 177,181p builtin-receive-pack.c
/* only refs/... are allowed */
if (prefixcmp(name, "refs/") || check_ref_format(name + 5)) {
error("refusing to create funny ref '%s' remotely", name);
return "funny refname";
}
-Peff
^ permalink raw reply
* Re: error pushing stash ?
From: Jeff King @ 2008-10-28 21:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Bryson, git
In-Reply-To: <20081007004051.GA18889@spearce.org>
On Mon, Oct 06, 2008 at 05:40:51PM -0700, Shawn O. Pearce wrote:
> > ! [remote rejected] refs/stash -> refs/stash (funny refname)
> > error: failed to push some refs to '/users/dbryson/backup/janus.git/'
>
> refs/stash is a funny refname because it contains only 1 '/'.
> Normally a valid ref has at least 2 '/', e.g. refs/heads/8654 or
> refs/tags/v1.0.
Since no version of receive-pack accepts these "funny refs", perhaps we
should mirror the check when considering the list of refs to send. IOW,
don't even make them eligible for matching or mirroring. Patch is below.
> Naming the stash refs/stash was perhaps funny in the first place
> since it cannot be moved about on the transport protocol, but then
> again the bulk of the stash data is actually in the reflog for the
> stash (and not the stash ref itself) so there is basically no point
> in pushing or fetching a stash directly.
I agree there is not much point in pushing it, since the useful bit is
in the reflog. So perhaps a "funny" refname is a good place to put it,
since it easily tells us that it is not a useful thing to push.
---
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index bbf6e0a..298bd71 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -140,7 +140,13 @@ static struct ref *remote_refs, **remote_tail;
static int one_local_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
struct ref *ref;
- int len = strlen(refname) + 1;
+ int len;
+
+ /* we already know it starts with refs/ to get here */
+ if (check_ref_format(refname + 5))
+ return 0;
+
+ len = strlen(refname) + 1;
ref = xcalloc(1, sizeof(*ref) + len);
hashcpy(ref->new_sha1, sha1);
memcpy(ref->name, refname, len);
^ permalink raw reply related
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Miklos Vajna @ 2008-10-28 21:10 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <20081028191234.GS24201@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> To sum up, I'm not so sure about a working hg fast-import is available
> at the moment.
I wrote too fast.
There is a minimal implementation here:
http://hg.opensource.lshift.net/hg-fastimport/
(I haven't tried it yet myself.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Christian Couder @ 2008-10-28 19:13 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83skqg1uc9.fsf@kalahari.s2.org>
On Tue, Oct 28, 2008 at 6:51 PM, Hannu Koivisto <azure@iki.fi> wrote:
> "Christian Couder" <christian.couder@gmail.com> writes:
>
>> Hi,
>>
>> On Tue, Oct 28, 2008 at 5:28 PM, Hannu Koivisto <azure@iki.fi> wrote:
>>> Greetings,
>>>
>>> git bisect view uses gitk if DISPLAY environment variable is set
>>> and git log otherwise. Since gitk doesn't require X server in
>>> Cygwin, that seems like a bit questionable condition in that
>>> environment.
>>
>> Do you know any environment variable that we could use to detect we
>> can use gitk in Cygwin?
>
> I looked around and I believe there is no such variable. I suppose
> the only case where you cannot use gitk is when the user is logged
> on using ssh, telnet, psexec or similar (well, unless you use some
> non-standard Tcl/Tk build which is configured to use X instead of
> Windows graphics). Then again, I don't think typical Windows
> programs do any checks for such situations.
We need at least a way to detect we are under Cygwin, because we won't
change the current behavior for all platforms.
Is checking for the CYGWIN environment variable enough?
> So, easy fix: always use gitk unless log is specified. Harder fix:
> figure out a way to test if the login session is such that
> graphical applications can be run.
>
>> You can use "git bisect view log" to use "git log" even if DISPLAY is set.
>
> I'd rather not use undocumented functionality ;)
In this case you can use any "git log" option after "git bisect view"
(for example: git bisect view -p).
Regards,
Christian.
^ permalink raw reply
* [StGit PATCH] Tutorial: Importing patches
From: Karl Hasselström @ 2008-10-28 20:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 89 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 2808462..283b358 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -621,7 +621,94 @@ get rid of such empty patches if you don't want them hanging around:
Importing patches
-----------------
-TODO:: import, ...
+While you are busy producing patches, there's hopefully someone -- the
+'maintainer' -- at the other end who recieves them and 'applies' them
+to her Git tree, which is then published for all (or parts of) the
+world to see.
+
+It's perfectly fine for this person to not have the foggiest idea what
+StGit is. In that case, she'll probably apply your patches with
+something like +git am+, and everything will just work, exactly as if
+you'd used Git to send those patches. But she might be an StGit user
+too, in which case she might use stglink:import[].
+
+There are basically four kinds if stuff you can import with
+stglink:import[]:
+
+ 1. A patch in a file.
+
+ 2. Several files containing one patch each, and a 'series' file
+ listing those other files in the correct order.
+
+ 3. An e-mail containing a single patch.
+
+ 4. A mailbox file (in standard Unix +mbox+ format) containing
+ multiple e-mails with one patch in each.
+
+
+Importing a plain patch
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Importing a plain patch, such as produced by e.g. GNU +diff+, +git
+diff+, +git show+, stglink:diff[], or stglink:show[], is very easy.
+Just say
+
+ $ stg import my-patch
+
+and you'll have a new patch at the top of your stack.
+
+If you don't give a file name on the command line, stglink:import[]
+will read the patch from its standard input -- in other words, you can
+pipe a patch to it directly from the command that produces it.
+
+By default, the new patch's name will be taken from the file name, and
+its commit message and author info will be taken from the beginning of
+the patch, if they are there. However, there are command line switches
+to override all of these things; see the man page for details.
+
+
+Importing several patches at once
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some programs -- among them stglink:export[] -- will create a bunch of
+files with one patch in each, and a 'series' file (often called
++series+) listing the other files in the correct order. Give
++$$--series$$+ and the name of the series file to stglink:import[],
+and it will import all the patches for you, in the correct order.
+
+
+Importing a patch from an e-mail
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Importing a patch from an e-mail is simple too:
+
+ $ stg import --mail my-mail
+
+The e-mail should be in standard Git mail format (which is what e.g.
+stglink:mail[] produces) -- that is, with the patch in-line in the
+mail, not attached. The authorship info is taken from the mail
+headers, and the commit message is read from the 'Subject:' line and
+the mail body.
+
+If you don't give a file name, the mail will be read from the standard
+input. This means that, if your mail reader supports it, you can pipe
+a mail directly to +stg import $$--mail$$+ and the patch will be
+applied.
+
+
+Importing a mailbox full of patches
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Finally, in case importing one patch at a time is too much work,
+stglink:import[] also accepts an entire Unix +mbox+-format mailbox,
+either on the command line or on its standard input; just use the
++$$--mbox$$+ flag. Each mail should contain one patch, and is imported
+just like with +$$--mail$$+.
+
+Mailboxes full of patches are produced by e.g. stglink:mail[] with the
++$$--mbox$$+ flag, but most mail readers can produce them too, meaning
+that you can copy all the patch mails you want to apply to a separate
+mailbox, and then import them all in one go.
Other stuff that needs to be placed somewhere
^ permalink raw reply related
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 20:27 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028200901.GA2894@artemis.mtv.corp.google.com>
On Tue, Oct 28, 2008 at 09:09:02PM +0100, Pierre Habouzit wrote:
> > Hmm. Why a date-based hack to see what's on the topic branch? Why not
> > just give an option to walk the graph twice,
>
> it serves the purpose to not walk the graph twice actually, but indeed
> twice is not _that_ bad.
Sure, and that is reasonable. But I think the real goal is "give this
information in a not-painfully slow manner". So if we can do it by
walking a smaller graph twice, I think that is OK, too.
> Well, I was just thinking quickly during jetlag-induced insomnia. I
> don't really care about the issue that much actually.
Heh. I have to admit I don't care enough to work on this personally,
either. I just _thought_ Linus was working on it, but I think what he is
doing is subtly different, and our discussion has diverged to something
that, if it ever came to pass, would be a separate feature.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Pierre Habouzit @ 2008-10-28 20:09 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028194642.GB752@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
On Tue, Oct 28, 2008 at 07:46:43PM +0000, Jeff King wrote:
> On Tue, Oct 28, 2008 at 02:11:16PM +0100, Pierre Habouzit wrote:
> > believe the proper way to do that is to help git-log knowing which are
> > the short (topic) branches, and to crawl incrementally using a
> > date-based hack. This would basically work a bit like this. Let's
> > imaging you want to crawl "next" in git and know which topics from pu
> > are in it. You would say e.g.:
>
> Hmm. Why a date-based hack to see what's on the topic branch? Why not
> just give an option to walk the graph twice,
it serves the purpose to not walk the graph twice actually, but indeed
twice is not _that_ bad.
> giving name-rev style annotations, and just let it be slow. People
> will mostly look at it by specifying just their topic branches anyway.
> IOW:
>
> git log ^origin/master my/topic1 my/topic2 my/topic3
>
> and by virtue of the fact that you are vastly limiting the size of the
> tree, it won't actually end up too slow. So you haven't said so much
> "these are my topic branches" as "I am just not interested in things
> that are already upstream."
Well, I was just thinking quickly during jetlag-induced insomnia. I
don't really care about the issue that much actually.
--
·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: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 19:53 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028194642.GB752@sigill.intra.peff.net>
On Tue, Oct 28, 2008 at 03:46:43PM -0400, Jeff King wrote:
>
> Hmm. Why a date-based hack to see what's on the topic branch? Why not
> just give an option to walk the graph twice, giving name-rev style
> annotations, and just let it be slow. People will mostly look at it by
> specifying just their topic branches anyway. IOW:
>
> git log ^origin/master my/topic1 my/topic2 my/topic3
And obviously you could split the "these are the commits to annotate"
specification from "these are the commits to show". But I actually think
in practice most users would want those to be the same.
-Peff
^ 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