* Re: [RFC] strbuf's in builtin-apply
From: Pierre Habouzit @ 2007-09-15 17:07 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20070915141210.GA27494@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
On Sat, Sep 15, 2007 at 02:12:10PM +0000, Pierre Habouzit wrote:
> + nsize = buf->len;
> + nbuf = convert_to_git(path, buf->buf, &nsize);
> + if (nbuf)
> + strbuf_embed(buf, nbuf, nsize, nsize);
Okay, I managed to be able to be sure that convert_to_git always have
an extra ending NUL byte, with an intermediate patch. So now I call
strbuf_embed with nsize, nsize + 1 which has negligible cost.
Though this question remains:
> Another suspicious hunk is:
>
> - data = (void*) fragment->patch;
> [...]
> case BINARY_LITERAL_DEFLATED:
> - free(desc->buffer);
> - desc->buffer = data;
> - dst_size = fragment->size;
> - break;
> + strbuf_embed(buf, fragment->patch, fragment->size, fragment->size);
> + return 0;
>
> TTBOMK the ->patch pointer is a pointer inside a buffer, not a buffer
> that has been malloc'ed (and there are code paths before my patch that
> would still realloc the buffer so I don't think I introduce an issue).
> It passes the test-suite without crashing, but well, maybe this should
> be a copy instead.
>
> The rest is pretty straightforward.
>
> --
> ·O· Pierre Habouzit
> ··O madcoder@debian.org
> OOO http://www.madism.org
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Data Integrity & un-Commited Branches
From: Nikodemus Siivola @ 2007-09-15 17:14 UTC (permalink / raw)
To: David Kastrup; +Cc: Shawn O. Pearce, Jan Hudec, Brian Scott Dobrovodsky, git
In-Reply-To: <85myvoav1g.fsf@lola.goethe.zz>
On 9/15/07, David Kastrup <dak@gnu.org> wrote:
> "Take a while"? What's wrong with git-reflog?
Not needing it as a part of my regular workflow, and therefore
not thinking about it. *blush*
Cheers,
-- Nikodemus
^ permalink raw reply
* Re: STG, problem with pop/push of alternative versions of a patch
From: Catalin Marinas @ 2007-09-15 17:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910709150725k73bec66bw753c4b3c01244cff@mail.gmail.com>
On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/15/07, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > I trying to test two different versions of a patch that add files.
> > > These patches create a new directory and add several files. When I pop
> > > a version of the patch the directory and files and not getting
> > > removed. This causes an error when I push the alternative version of
> > > the patch.
> >
> > This shouldn't happen AFAICT (at least for the files, as GIT doesn't
> > care much about directories). What GIT/StGIT version are you using?
> > StGIT simply calls GIT to do the HEAD switch.
>
> I have played around with some more. It is more complicated than the
> simple case I described. Earlier I noticed a message about applying a
> patch that was empty that shouldn't have been. I checked and the patch
> is indeed empty. The empty patch probably caused the files to be left.
> I had been using hide/unide and reordering with on the patch and had
> encountered a couple errors in stg. I'll try and track down the
> sequence that caused the contents of the patch to be lost.
BTW, you can run 'stg log <patch>' to see how the patch was changed.
It even has a -g option to invoke gitk and see each change.
One way a patch could become empty is if the changes it makes are
already in the repository (in another patch or merged upstream).
--
Catalin
^ permalink raw reply
* Re: Data Integrity & un-Commited Branches
From: David Kastrup @ 2007-09-15 17:33 UTC (permalink / raw)
To: Nikodemus Siivola
Cc: Shawn O. Pearce, Jan Hudec, Brian Scott Dobrovodsky, git
In-Reply-To: <6bcc356f0709151014j9606a3ape6b62770304560ba@mail.gmail.com>
"Nikodemus Siivola" <nikodemus@random-state.net> writes:
> On 9/15/07, David Kastrup <dak@gnu.org> wrote:
>
>> "Take a while"? What's wrong with git-reflog?
>
> Not needing it as a part of my regular workflow, and therefore
> not thinking about it. *blush*
"Oh no, what have I done now?"
I am afraid that working with git still exposes me to this question
time and again. And git-reflog usually provides the answer, as well
as what I need to recover.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] revision walker: --cherry-pick is a limited operation
From: Johannes Schindelin @ 2007-09-15 17:39 UTC (permalink / raw)
To: mbaehr, gitster, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1872 bytes --]
We used to rely on the fact that cherry-pick would trigger the code path
to set limited = 1 in handle_commit(), when an uninteresting commit was
encountered.
However, when cherry picking between two independent branches, i.e. when
there are no merge bases, and there is only linear development (which can
happen when you cvsimport a fork of a project), no uninteresting commit
will be encountered.
So set limited = 1 when --cherry-pick was asked for.
Noticed by Martin Bähr.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
revision.c | 1 +
t/t6007-rev-list-cherry-pick-file.sh | 14 ++++++++++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index c193c3e..33d092c 100644
--- a/revision.c
+++ b/revision.c
@@ -1024,6 +1024,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
}
if (!strcmp(arg, "--cherry-pick")) {
revs->cherry_pick = 1;
+ revs->limited = 1;
continue;
}
if (!strcmp(arg, "--objects")) {
diff --git a/t/t6007-rev-list-cherry-pick-file.sh b/t/t6007-rev-list-cherry-pick-file.sh
index 3faeae6..4b8611c 100755
--- a/t/t6007-rev-list-cherry-pick-file.sh
+++ b/t/t6007-rev-list-cherry-pick-file.sh
@@ -40,4 +40,18 @@ test_expect_success '--cherry-pick bar does not come up empty' '
! test -z "$(git rev-list --left-right --cherry-pick B...C -- bar)"
'
+test_expect_success '--cherry-pick with independent, but identical branches' '
+ git symbolic-ref HEAD refs/heads/independent &&
+ rm .git/index &&
+ echo Hallo > foo &&
+ git add foo &&
+ test_tick &&
+ git commit -m "independent" &&
+ echo Bello > foo &&
+ test_tick &&
+ git commit -m "independent, too" foo &&
+ test -z "$(git rev-list --left-right --cherry-pick \
+ HEAD...master -- foo)"
+'
+
test_done
--
1.5.3.1.949.g98c3
^ permalink raw reply related
* Re: STG, problem with pop/push of alternative versions of a patch
From: Jon Smirl @ 2007-09-15 17:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <b0943d9e0709151031m70b9d03bw4068805e697e97f5@mail.gmail.com>
On 9/15/07, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 9/15/07, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > > On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > I trying to test two different versions of a patch that add files.
> > > > These patches create a new directory and add several files. When I pop
> > > > a version of the patch the directory and files and not getting
> > > > removed. This causes an error when I push the alternative version of
> > > > the patch.
> > >
> > > This shouldn't happen AFAICT (at least for the files, as GIT doesn't
> > > care much about directories). What GIT/StGIT version are you using?
> > > StGIT simply calls GIT to do the HEAD switch.
> >
> > I have played around with some more. It is more complicated than the
> > simple case I described. Earlier I noticed a message about applying a
> > patch that was empty that shouldn't have been. I checked and the patch
> > is indeed empty. The empty patch probably caused the files to be left.
> > I had been using hide/unide and reordering with on the patch and had
> > encountered a couple errors in stg. I'll try and track down the
> > sequence that caused the contents of the patch to be lost.
>
> BTW, you can run 'stg log <patch>' to see how the patch was changed.
> It even has a -g option to invoke gitk and see each change.
>
> One way a patch could become empty is if the changes it makes are
> already in the repository (in another patch or merged upstream).
I was not happy when my patch disappeared. Luckily I had exported it a
little while earlier.
This error may have messed up my state and I didn't detect it until
later. 0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
is the patch that went missing.
---------- Forwarded message ----------
From: Jon Smirl <jonsmirl@gmail.com>
Date: Sep 13, 2007 4:08 PM
Subject: Stg AssertionError in sink command
To: Git Mailing List <git@vger.kernel.org>, catalin.marinas@gmail.com
Using current git source for Stg
Patch 008 was hidden and I used unhide to bring it back. But the
hide/unhide process moved it to the top of the stack. I need to sink
it back down to where it came from. Shouldn't hide/unhide preserve the
patch position in the stack?
jonsmirl@terra:~/mpc5200b$ stg series
+ 0001-powerpc-exports-rheap-symbol-to-modules.patch
+ 0002-powerpc-Changes-the-config-mechanism-for-rheap.patch
+ 0003-powerpc-ppc32-Update-mpc52xx_psc-structure-with-B-r.patch
+ 0004-powerpc-BestComm-core-support-for-Freescale-MPC5200.patch
+ 0005-powerpc-BestcComm-ATA-task-support.patch
+ 0006-powerpc-BestcComm-FEC-task-support.patch
> 0007-powerpc-BestcComm-GenBD-task-support.patch
- domen-fec
- 0009-sound-Add-support-for-Freescale-MPC5200-AC97-interf.patch
- 0010-powerpc-In-rheap.c-move-the-EXPORT_SYMBOL-and-use.patch
- 0011-powerpc-BestComm-move-the-EXPORT_SYMBOL-and-use-th.patch
- 0012-powerpc-BestComm-ATA-task-move-the-EXPORT_SYMBOL-a.patch
- 0013-powerpc-BestComm-FEC-task-move-the-EXPORT_SYMBOL-a.patch
- 0014-powerpc-BestComm-GenBD-task-move-the-EXPORT_SYMBOL.patch
- 0015-powerpc-BestComm-Replace-global-variable-bcom-by-b.patch
- 0016-powerpc-Make-the-BestComm-driver-a-standard-of_plat.patch
- 0017-powerpc-Fix-typo-in-BestComm-ATA-task-support-code.patch
- 0018-powerpc-BestComm-ATA-task-microcode-insert-copyri.patch
- 0019-powerpc-BestComm-FEC-task-microcode-insert-copyri.patch
- 0020-powerpc-BestComm-GenBD-task-microcode-insert-copy.patch
- 0021-powerpc-Fix-errors-in-bcom-bcom_eng-renaming.patch
- Makefile
- pcm030_bsp_powerpc
- fs_jffs2_use_memcpy_fromio
- gpio_frame
- ppc_gpio
- GPIO-adaption
- mpc52xx_restart
- pcm_dts_eth_phys
- 0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
jonsmirl@terra:~/mpc5200b$ stg sink -t domen-fec
0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
Checking for changes in the working directory ... done
Traceback (most recent call last):
File "/usr/local/bin/stg", line 43, in <module>
main()
File "/usr/local/lib/python2.5/site-packages/stgit/main.py", line 284, in main
command.func(parser, options, args)
File "/usr/local/lib/python2.5/site-packages/stgit/commands/sink.py",
line 58, in func
crt_series.pop_patch(options.to or oldapplied[0])
File "/usr/local/lib/python2.5/site-packages/stgit/stack.py", line
1129, in pop_patch
assert(name in applied)
AssertionError
jonsmirl@terra:~/mpc5200b$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: Johannes Schindelin @ 2007-09-15 17:43 UTC (permalink / raw)
To: Grzegorz Kulewski
Cc: martin f krafft, git, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz, David Härdeman
In-Reply-To: <Pine.LNX.4.63.0709151819200.19941@alpha.polcom.net>
Hi,
On Sat, 15 Sep 2007, Grzegorz Kulewski wrote:
> On Sat, 15 Sep 2007, martin f krafft wrote:
> > I understand also that this is not top priority for git, which is why
> > I said earlier in the thread that the real difficulty might be to get
> > Junio to accept a patch. But I think that the patch would be rather
> > contained and small, having it all configurable would make it
> > unintrusive, and if we all test it real well, it should pass as a
> > bonus. After all, git can e.g upload patches to IMAP boxes, which in
> > my world clearly is bonus material as well.
>
> I also think such configuration option would be cool.
Why don't you just give it a try? Hack on git, make it work for what you
want to do, clean it up, make a nice patch series, post it here.
Then we'll talk.
Ciao,
Dscho
^ permalink raw reply
* Conflicting "-n" short options for git-pull?
From: Frans Pop @ 2007-09-15 19:14 UTC (permalink / raw)
To: git
Hello,
According to the man page for git-pull from git-core 1.5.3.1 (Debian
package), two options are defined as having the short option "-n":
-n, --no-summary
Do not show diffstat at the end of the merge.
[...]
-n, --no-tags
By default, git-fetch fetches tags that point at objects that are
downloaded from the remote repository and stores them locally. This
option disables this automatic tag following.
Cheers,
Frans Pop
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: Daniel Barkalow @ 2007-09-15 19:56 UTC (permalink / raw)
To: martin f krafft
Cc: git, Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz, David Härdeman
In-Reply-To: <20070915145437.GA12875@piper.oerlikon.madduck.net>
On Sat, 15 Sep 2007, martin f krafft wrote:
> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.15.1610 +0200]:
> > No. Git is a source code management system. Everything else that
> > you can do with it is a bonus, a second class citizen. Should we
> > really try to support your use case, we will invariably affect the
> > primary use case.
>
> I thought git was primarily a content tracker... so it all comes
> down to how to define content, doesn't it? But either way, we need
> not discuss that because that definition depends a lot on context
> and purpose and thus cannot be answered once and for all.
>
> I understand that for the primary use case, tracking nothing more
> than +x makes sense and should not be interfered with. This is why
> I was proposing a policy-based approach. The primary use case is
> unaffected, it's the default policy. Someone may choose to track
> other mode bits or file/inode attributes, according to one of
> several policies available with git, or even a custom policy. In
> that case, the repository needs to be appropriately configured.
Configuration options only apply to the local aspects of the repository.
That is, when you clone a repository, you don't get the configuration
options from it, in general. And changing configuration options on a
repository does not have any effect on the content it contains. So
configuration options aren't appropriate.
> The reason why I say this should be done inside git rather than with
> hooks and an external tool, such as metastore is quite simple: git
> knows about every content entity in any tree of a repo and already
> has a data node for each object. Rather than introducing a parallel
> object database (shadow hierarchy or single file), it would make
> a lot more sense and be way more robust to attach additional
> information to these object nodes, wouldn't it?
Git doesn't have any way to represent owners or groups, and they would
need to be represented carefully in order to make sense across multiple
computers. If you're adding support for metadata-as-content (for more than
"is this a script?"), you should be able to cover all of the common cases
of extended stuff, like AFS-style ACLs. And if you want to allow
meaningful development with this mechanism (as opposed to just archival of
a sequence of states of a live system), the normal case will be that the
metadata beyond +x is manipulated by ordinary users in some way other than
modifying their working directory. So the normal case here will be like
working on a filesystem that doesn't support symlinks or an executable bit
when this is important content.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git-sh-setup.sh
From: Anupam Srivastava @ 2007-09-15 20:38 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 147 bytes --]
English is not my native language but I think this patch corrects a
grammar mistake.
I am not subscribed so please CC to me if replying.
Anupam
[-- Attachment #2: doc.patch --]
[-- Type: text/x-patch, Size: 459 bytes --]
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 185c5c6..3c325fd 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -6,7 +6,7 @@
# it dies.
# Having this variable in your environment would break scripts because
-# you would cause "cd" to be be taken to unexpected places. If you
+# you would cause "cd" to be taken to unexpected places. If you
# like CDPATH, define it for your interactive shell sessions without
# exporting it.
unset CDPATH
^ permalink raw reply related
* Re: metastore (was: Track /etc directory using Git)
From: Johannes Schindelin @ 2007-09-15 22:14 UTC (permalink / raw)
To: Daniel Barkalow
Cc: martin f krafft, git, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz, David Härdeman
In-Reply-To: <Pine.LNX.4.64.0709151430040.5298@iabervon.org>
Hi,
On Sat, 15 Sep 2007, Daniel Barkalow wrote:
> Git doesn't have any way to represent owners or groups, and they would
> need to be represented carefully in order to make sense across multiple
> computers.
[speaking mostly to the proponents of git-as-a-backup-tool]
While at it, you should invent a fallback what to do when the owner is not
present on the system you check out on. And a fallback when checking out
on a filesystem that does not support owners.
And a fallback when a non-root user uses it.
Oh, and while you're at it (you said that it would be nice not to restrict
git in any way: "it is a content tracker") support the Windows style
"Group-or-User-or-something:[FRW]" ACLs.
Looking forward to your patches,
Dscho
^ permalink raw reply
* Re: Stg AssertionError in sink command
From: Catalin Marinas @ 2007-09-15 22:37 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910709131308la9b3e44le70e1fac2b339189@mail.gmail.com>
On 13/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> Patch 008 was hidden and I used unhide to bring it back. But the
> hide/unhide process moved it to the top of the stack. I need to sink
> it back down to where it came from. Shouldn't hide/unhide preserve the
> patch position in the stack?
I now got the time to read this thread in more detail.
The initial implementation of hide/unhide was to preserve the patch
position in the stack. This behaviour was really confusing for people
since pushing a patch after the hidden one actually forced the pushing
of the hidden patch, which isn't normally shown by 'series'. I decided
afterwards to create a third category of patches - 'hidden' (the other
two being applied and unapplied). This cleared the unpredictable
behaviour when pushing since hidden patches cannot be pushed.
Karl's patch does the correct thing of raising an error if sinking
below an unapplied patch.
I implemented the hidden patches feature just to hide some patches I
no longer need (various tests or early prototypes of some patches) but
I still want to keep them around in case I have to look again.
Regarding the reordering of the unapplied patches, at the moment you
can (but I *don't* recommend) edit .git/patches/<branch>/unapplied.
Maybe the 'float' and 'sink' functionality could be modified to also
act on unapplied patches (with a --unapplied option). I don't think a
separate command would be needed as it duplicates a lot of
functionality from the above.
--
Catalin
^ permalink raw reply
* Re: STG, problem with pop/push of alternative versions of a patch
From: Catalin Marinas @ 2007-09-15 22:44 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910709151042p7c681e25o386be2ca2719daa9@mail.gmail.com>
On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> I was not happy when my patch disappeared. Luckily I had exported it a
> little while earlier.
Otherwise, the patch log should be present and it shows each commit id
of the patch.
Since we are at this, I think we need a config option to automatically
back up (export) the patches. Since StGIT detects whether the patch
applied cleanly or it was modified (with a diff3 merge), it only needs
to export in a few cases and not affect the performance (diff3 takes
significantly longer anyway).
Thanks for reporting this issue.
--
Catalin
^ permalink raw reply
* git-svn error when cloning apache repo
From: Jing Xue @ 2007-09-15 23:08 UTC (permalink / raw)
To: git
I'm trying to clone the Apache Ivy repo and got this error. What does
the "Using higher level of URL" mean? Also, of course, what does the
error message mean?
$ git svn clone https://svn.apache.org/repos/asf/incubator/ivy/core/ ivy-core -T trunk -b branches -t tags
Initialized empty Git repository in .git/
Using higher level of URL: https://svn.apache.org/repos/asf/incubator/ivy/core => https://svn.apache.org/repos/asf
W: Ignoring error from SVN, path probably does not exist: (175002): RA layer request failed: REPORT request failed on '/repos/asf/!svn/bc/100': REPORT of '/repos/asf/!svn/bc/100': Could not read chunk size: Secure connection truncated (https://svn.apache.org)
branch_from: /incubator/ivy/tags => /incubator/ivy/tags/1.4.1
Found possible branch point: https://svn.apache.org/repos/asf/incubator/ivy/tags/1.4.1 => https://svn.apache.org/repos/asf/incubator/ivy/core/tags/1.4.1, 499505
Initializing parent: tags/1.4.1@499505
Found possible branch point: https://svn.apache.org/repos/asf/incubator/ivy/trunk => https://svn.apache.org/repos/asf/incubator/ivy/tags/1.4.1, 488008
Initializing parent: tags/1.4.1@488008
RA layer request failed: REPORT request failed on '/repos/asf/!svn/vcc/default': REPORT of '/repos/asf/!svn/vcc/default': 400 Bad Request (https://svn.apache.org) at /home/jingxue/bin/git-svn line 3155
Any thoughts are appreciated.
Thanks.
--
Jing Xue
^ permalink raw reply
* Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch
From: Karl Hasselström @ 2007-09-15 23:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, git
In-Reply-To: <9e4733910709140918wbe94b5eu6ec326b25b0f3d42@mail.gmail.com>
On 2007-09-14 12:18:17 -0400, Jon Smirl wrote:
> On 9/14/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > $ stg pop p2 p3
> > $ stg push p3 p2
> >
> > Does this cover what you had in mind?
>
> Sure this works. I'm just wondering if it is a good idea to have
> separate reordering commands for patches that are applied vs
> unapplied. The separate commands confused me.
>
> Would it be better to simply prohibit reordering of apply patches
> and require that they be popped before they can be reordered? A
> sink/float that causes merge errors must be a mess to sort out.
It's not a mess, actually -- it's implemented in terms of push and pop
of single patches, so the theory is dead simple. (The push and pop
commands are also implemented in terms of push and pop of single
patches.)
> If you prohibit reordering of applied patches sink/float can be
> eliminated.
But they're useful! Though as I said earlier, they're implemented in
terms of push and pop, so they're technically redundant. But "sink p5
--to p2" would be "pop p3..p5 && push p5 p3 p4", which is more typing
(starting with applied patches p1, p2, p3, p4, p5).
> Another way to handle this would be to eliminate the ability of
> pop/push to reorder and extend sink/float to handle unapplied
> patches.
I think that I'd like the latter without the former -- that is,
teaching sink/float how to handle unapplied patches, and leaving
push/pop as is. That'll let you do what you tried to do in the first
place, and will leave us with a more redundant command set, but I
don't think that's bad.
Another idea that's been kicked around is to have a general reorder
command, that spawns an editor and lets you move around (and delete)
patch names until you're satisfied. (This too would be implemented in
terms of push and pop of single patches.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: StGIT patch editing command
From: Karl Hasselström @ 2007-09-15 23:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0709141057i7d03a2b6n408b820926cd95a5@mail.gmail.com>
On 2007-09-14 18:57:43 +0100, Catalin Marinas wrote:
> Since some people mentioned in the past that it would be nice to be
> able to edit patches, including the diff, I added the 'edit' command
> in today's snapshot (and StGIT repository).
Sounds great! I won't have time to test drive it for a few days,
though.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: metastore
From: Randal L. Schwartz @ 2007-09-15 23:33 UTC (permalink / raw)
To: Grzegorz Kulewski
Cc: martin f krafft, git, Johannes Schindelin, Thomas Harning Jr.,
Francis Moreau, Nicolas Vilz, David Härdeman
In-Reply-To: <Pine.LNX.4.63.0709151819200.19941@alpha.polcom.net>
>>>>> "Grzegorz" == Grzegorz Kulewski <kangur@polcom.net> writes:
Grzegorz> Not only for tracking /etc or /home but also for example for "web
Grzegorz> applications" (for example in PHP). In that case file and directory
Grzegorz> permissions can be as important as the source code tracked and it is pain to
Grzegorz> chmod (and sometimes chown) all files to different values after each
Grzegorz> checkout. Not speaking about potential race.
Uh, works just fine for me to manage my web site content. The point is
that I treat git for what it is... a source code management system.
And then I have a Makefile that "installs" my source code into the live
directory, with the right modes during installation.
Why does everyone keep wanting "work dir == live dir". Ugh! The work dir is
the *source*... it gets *copied* into your live dir *somehow*. And *that* is
where the meta information needs to be. In that "somehow".
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [StGit PATCH 13/13] Remove the 'top' field
From: Karl Hasselström @ 2007-09-15 23:36 UTC (permalink / raw)
To: David Kågedal; +Cc: git, catalin.marinas
In-Reply-To: <20070914223215.7001.80066.stgit@morpheus.local>
On 2007-09-15 00:32:15 +0200, David Kågedal wrote:
> @@ -436,7 +422,13 @@ class Series(PatchSet):
> patch = patch.strip()
> os.rename(os.path.join(branch_dir, patch),
> os.path.join(patch_dir, patch))
> - Patch(patch, patch_dir, refs_base).update_top_ref()
> + topfield = os.path.join(patch_dir, patch, 'top')
> + if os.path.isfile(topfield):
> + top = read_string(topfield, False)
> + else:
> + top = None
> + if top:
> + git.set_ref(refs_base + '/' + patch, top)
> set_format_version(1)
>
> # Update 1 -> 2.
And remove the top file, maybe? (Or I may be mistaken; I don't have a
copy of the surrounding code handy.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Conflicting "-n" short options for git-pull?
From: Junio C Hamano @ 2007-09-15 23:39 UTC (permalink / raw)
To: Frans Pop; +Cc: git
In-Reply-To: <200709152114.54985.elendil@planet.nl>
Frans Pop <elendil@planet.nl> writes:
> According to the man page for git-pull from git-core 1.5.3.1 (Debian
> package), two options are defined as having the short option "-n":
>
> -n, --no-summary
> Do not show diffstat at the end of the merge.
> [...]
> -n, --no-tags
> By default, git-fetch fetches tags that point at objects that are
> downloaded from the remote repository and stores them locally. This
> option disables this automatic tag following.
The manpage option descriptions are shared between the
commands. Maybe we should drop mention of the shorthand form.
When git-fetch is used -n means --no-tags because there is no
other -n; when git-pull indirectly invokes git-fetch, you need
to spell it --no-tags because --no-summary takes precedence.
^ permalink raw reply
* Re: [StGit PATCH 00/13] Eliminate 'top' and 'bottom' files
From: Karl Hasselström @ 2007-09-15 23:42 UTC (permalink / raw)
To: David Kågedal; +Cc: git, catalin.marinas
In-Reply-To: <20070914222819.7001.55921.stgit@morpheus.local>
On 2007-09-15 00:31:09 +0200, David Kågedal wrote:
> The following series removes the 'bottom' and 'top' files for each
> patch, and instead uses the commit objects to keep track of the
> patches.
Wonderful! Does this ensure that there's a bijection between patches
and commits at _all_ times, or am I missing something?
> The last two patches do the final cleansing. Obviously, this changes
> the format, and the format version should be increased and and
> update function be written. So it's not really ready to go in yet.
It's a trivial format update, though: just delete those two files and
increase the number from 2 to 3.
Hmm, wait, no. Right. We also have to create commits for those patches
that don't have exactly one commit object. Not that there'll be many
of them, but better not make assumptions ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Stg AssertionError in sink command
From: Karl Hasselström @ 2007-09-15 23:52 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <b0943d9e0709151537k51f2f8d5w5a9bbfef84f82747@mail.gmail.com>
On 2007-09-15 23:37:21 +0100, Catalin Marinas wrote:
> The initial implementation of hide/unhide was to preserve the patch
> position in the stack. This behaviour was really confusing for
> people since pushing a patch after the hidden one actually forced
> the pushing of the hidden patch, which isn't normally shown by
> 'series'. I decided afterwards to create a third category of patches
> - 'hidden' (the other two being applied and unapplied). This cleared
> the unpredictable behaviour when pushing since hidden patches cannot
> be pushed.
I agree that the new semantics is way saner (though I'm still not
entirely convinced that hiding patches is a good idea in the first
place). But the man pages should probably point out clearly that
hidden patches must be unapplied.
> Karl's patch does the correct thing of raising an error if sinking
> below an unapplied patch.
>
> Regarding the reordering of the unapplied patches, at the moment you
> can (but I *don't* recommend) edit .git/patches/<branch>/unapplied.
> Maybe the 'float' and 'sink' functionality could be modified to also
> act on unapplied patches (with a --unapplied option). I don't think
> a separate command would be needed as it duplicates a lot of
> functionality from the above.
Why the extra option? Just do the right thing, since it's unambiguous
what the right thing is.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: metastore
From: david @ 2007-09-16 0:37 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Grzegorz Kulewski, martin f krafft, git, Johannes Schindelin,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <86veaby050.fsf@blue.stonehenge.com>
On Sat, 15 Sep 2007, Randal L. Schwartz wrote:
>>>>>> "Grzegorz" == Grzegorz Kulewski <kangur@polcom.net> writes:
>
> Grzegorz> Not only for tracking /etc or /home but also for example for "web
> Grzegorz> applications" (for example in PHP). In that case file and directory
> Grzegorz> permissions can be as important as the source code tracked and it is pain to
> Grzegorz> chmod (and sometimes chown) all files to different values after each
> Grzegorz> checkout. Not speaking about potential race.
>
> Uh, works just fine for me to manage my web site content. The point is
> that I treat git for what it is... a source code management system.
> And then I have a Makefile that "installs" my source code into the live
> directory, with the right modes during installation.
>
> Why does everyone keep wanting "work dir == live dir". Ugh! The work dir is
> the *source*... it gets *copied* into your live dir *somehow*. And *that* is
> where the meta information needs to be. In that "somehow".
the problem is that at checkin you need to do the reverse process. the
other tools that you use on the system work on the live dir, not the 'work
dir', so it's only a 'work dir' in that git requires it as an staging step
between the repository and the place where it's going to be used.
David Lang
^ permalink raw reply
* Re: [PATCH] builtin-apply: use strbuf's instead of buffer_desc's.
From: Junio C Hamano @ 2007-09-16 0:56 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070915141340.334CA4C152@madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> 1 files changed, 73 insertions(+), 130 deletions(-)
Nice reduction.
> - }
> - return got != size;
> +
> + nsize = buf->len;
> + nbuf = convert_to_git(path, buf->buf, &nsize);
> + if (nbuf)
> + strbuf_embed(buf, nbuf, nsize, nsize);
> + return 0;
I suspect that changing the convert_to_git() interface to work
on strbuf instead of (char*, size_t *) pair might make things
simpler and easier.
^ permalink raw reply
* Re: [PATCH] New strbuf APIs: splice and embed.
From: Junio C Hamano @ 2007-09-16 0:57 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070915141335.ECB4B4C152@madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> * strbuf_splice replace a portion of the buffer with another.
> * strbuf_embed replace a strbuf buffer with the given one, that should be
> malloc'ed. Then it enforces strbuf's invariants. If alloc > len, then this
> function has negligible cost, else it will perform a realloc, possibly
> with a cost.
"embed" does not sound quite right, does it? It is a reverse
operation of strbuf_detach() as far as I can tell.
> -void strbuf_rtrim(struct strbuf *sb)
> -{
> +void strbuf_rtrim(struct strbuf *sb) {
> while (sb->len > 0 && isspace((unsigned char)sb->buf[sb->len - 1]))
> sb->len--;
> sb->buf[sb->len] = '\0';
This is changing the style in the wrong direction, isn't it? We
start our functions like this:
type name(proto)
{
...
> +void strbuf_splice(struct strbuf *sb, size_t pos, size_t len,
> + const void *data, size_t dlen)
> +{
> + if (pos + len < pos)
> + die("you want to splice outside from the buffer");
That is a funny error message for an integer wrap-around check.
> + if (pos > sb->len)
> + pos = sb->len;
Shouldn't this be flagged as a programming error?
> + if (pos + len > sb->len)
> + len = sb->len - pos;
Likewise.
By the way, this is the kind of situation I wish everybody wrote
their comparison in textual order. I had to draw a picture like
this to see what was going on.
sb->buf
xxxxxxxxxxxzzzzzxxxxxxxxxxx\0
^ ^
0 sb->len
^ ^ ^ ^
pos pos+len pos pos+len
v v
yyyyyyyyyy yyyyyyyyyy
^ ^
dlen dlen
------------- --------------
pos < sb->len sb->len < pos
^ permalink raw reply
* Re: metastore
From: Randal L. Schwartz @ 2007-09-16 1:10 UTC (permalink / raw)
To: david
Cc: Grzegorz Kulewski, martin f krafft, git, Johannes Schindelin,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz,
David Härdeman
In-Reply-To: <Pine.LNX.4.64.0709151733260.24221@asgard.lang.hm>
>>>>> "david" == david <david@lang.hm> writes:
>> Why does everyone keep wanting "work dir == live dir". Ugh! The work dir is
>> the *source*... it gets *copied* into your live dir *somehow*. And *that* is
>> where the meta information needs to be. In that "somehow".
david> the problem is that at checkin you need to do the reverse process. the
david> other tools that you use on the system work on the live dir, not the
david> 'work dir', so it's only a 'work dir' in that git requires it as an
david> staging step between the repository and the place where it's going to
david> be used.
Eh? Are we still talking about a "website", or "/etc"? I'm talking about the
website case. I don't do *anything* to the live site. When I want to add a
file, I add it to my dev repo, possibly modifying my Makefile, and then spit
it out on my staging server. (You *do* have one of those, right?) Once I
know it's good, I push it to the live repo, and then "go live" with it. I
*never* work on the files that are the result of "make install".
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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