* Re: [PATCH 05/16] ls-files: add --narrow-checkout option to "will checkout" entries
From: Jakub Narebski @ 2008-09-14 18:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-6-git-send-email-pclouds@gmail.com>
I will comment only on the documentation...
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Even in narrow checkout mode, "git ls-files --cached" (and --stage)
> will show all entries in index. When those options are used together
> with --narrow-checkout, no-checkout entries will be skipped.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> index 9f85d60..f74b212 100644
> --- a/Documentation/git-ls-files.txt
> +++ b/Documentation/git-ls-files.txt
> @@ -72,6 +73,11 @@ OPTIONS
> to file/directory conflicts for checkout-index to
> succeed.
>
> +--narrow-checkout::
> + When narrow checkout is being used, this option together with other
> + index-based selection options like --cached or --stage, only narrowed
> + portion will be printed out.
> +
I would rather say, that if git-ls-files is requested to show index
content (by using selection options like --cached or --stage), then
by default it shows all entries, also those marked "no checkout".
With this option git-ls-files would show only files that would get
checked out.
BTW. I think here --narrow-checkout is a good name, even though
I prefer 'partial checkout' or 'sparse checkout', because here it
is about narrowing the list of paths from index shown.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 10/16] grep: skip files that have not been checked out
From: Jakub Narebski @ 2008-09-14 18:56 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-11-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> builtin-grep.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
No changes to Documentation/git-grep.txt?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 13/16] ls-files: add --narrow-match=spec option for testing narrow matching
From: Jakub Narebski @ 2008-09-14 18:58 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-14-git-send-email-pclouds@gmail.com>
I will comment only on documentation?
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> +--narrow-match=<narrow_spec>::
> + Narrow spec can be applied on ls-files output so that you can test
> + your spec. Can only be used with --cached. See linkgit:git-checkout[1]
> + for more information about narrow spec.
> +
Where were those changes to Documentation/git-checkout.txt?
I think it would better read if you said first what for is this option,
i.e. first that this option is to test <narrow_spec>.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 14/16] clone: support narrow checkout with --path option
From: Jakub Narebski @ 2008-09-14 19:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-15-git-send-email-pclouds@gmail.com>
I will comment only on the documentation...
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> +--path=<narrow_spec>::
> + A narrow checkout of HEAD is performed after clone is complete
> + with given narrow spec. Please refer to linkgit:git-checkout[1]
> + for more detail on narrow checkout and narrow spec.
Two questions. First, can you repeat those specifiers, i.e. use
"git clone --path=Documentation/ --path=.gitignore"?
Second, how `--path=<narrow_spec>` interacts with `-n' (no checkout).
Does it even have any sense? Perhaps those options should be mutually
incompatibile (and --bare and this option too)?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git at Better SCM Initiative comparison of VCS (long)
From: Dmitry Potapov @ 2008-09-14 19:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Alexey Mahotkin
In-Reply-To: <200809141948.07160.jnareb@gmail.com>
On Sun, Sep 14, 2008 at 07:48:05PM +0200, Jakub Narebski wrote:
>
> By the way, perhaps I haven't stressed this like I should, but the
> most important thing I wanted to ask git list about, besides insight
> in my comments and proposal for changes, was if it is possible
> using current hooks infrastructure to restrict changes coming from
> some account in such a way as to allow it only if all changes are
> restricted to specified directory.
I believe the update hook should be able to do that. You have oldrev and
newrev, so you can run "git diff --name-only oldrev newrev" and see what
files are going to change. And then verify that the user has the write
access to this directories or files.
I have not tried it yet, and I don't think we have a ready example of
how to do that, but I believe that the example of the update hook that
restricts user access based on the target branch can be used as a
starting point.
>
> IMHO "atomic commits" (or rather "atomic operations", see below) is
> about commit being either in full, or not done at all. The fact
> that SCM might need some manual steps to recover from failure shouldn't
> factor in evaluating this criterion.
Agreed. Your wording makes much more sense than what was used in the
above criterion.
>
> > Another thing here is that "git commit" is local, so I am not sure
> > if this question includes network operations...
>
> Well, I think this session would be better titled "Atomic Operations"
> or just "Atomicity". Although I'm not sure if for example in Git
> all operations are atomic under all conditions...
I believe that all git basic operations are atomic. In fact, you either
got a new revision with new SHA-1 or don't. Aborting operation may
leave some dangling objects, but it is okay, because they will be
garbage collected later. But I am not sure about additional utilities
such as git-svn. Git-svn uses rebase as it dcommits, being interrupted,
it may leave you in some strange state. It is possible to recover but
it may be not obvious for newbies. Other than that, I think everything
is very resilient to any interruption.
>
> But even if we leave it "Atomic Commits", as for centralized SCM
> commit includes network operation, to have centralized and distributed
> SCM on equal footing, for distributed SCM this in my opinion should
> mean both atomic commit, and atomic push. (And that should be stated
> explicitly in the description...)
Agreed.
>
> > So, perhaps, it should be two separate points:
> > - ability to preserve history of rename (with detail clarification
> > of what it means)
> > - ability to show renames in the project history
>
> That are points '1' and '2' on my list, perhaps stated bit differently:
> showing renames in full history / history of project as whole, and
> following history of a single file across renames.
I did not mean '1' and '2' as priorities, but that it is slightly
different features and both can be titled as support of renaming.
> >
> > Git tracks content rather than file-ids, and therefore it uses heuristics
> > for rename detection. This approach has an advantage of being able to
> > preserve history for code lines between files, which usually happens much
> > more often than file renaming.
>
> I would rather write
>
> Renames are supported for most practical purposes[1]. By design Git
> does heuristic <i>rename detection</i> (based on similarity score of
> pathnames and file contents), instead of doing rename tracking (which
> usually is based on some kind of file-ids). This approach allows for
> more generic content tracking of code movement (which usually happens
> much often than wholesame file renaming), e.g. in "git blame -C -C".
Sounds good to me. Perhaps, I would drop '(which usually... file-ids)'
to make the sentence a bit shorter.
> > It is whether modification to more than one file can be commited (and
> > propogated) atomically. I also suppose that those changes should be
> > shown in history as a single change (not many changes too different
> > files that took place in the same time and the same commit comment).
> >
> > However, the whole tree commit is a more strict requirement than
> > just being able to commit a group of changes atomically. For example,
> > "svn ci" creates a changeset and atomically store all its modification
> > on the server. Yet, it is not the whole tree commit, because the result
> > tree may differ from the tree that you commiting (files that are not
> > modified by changeset may differ).
>
> I think the gist of intent was to have revisions (revision identifiers)
> refer to the state of a whole repository (or to changes to the set of
> files as a whole: a changeset).
Perhaps. Though, then SVN should have 'Yes', but it listed as "partial
support." It seems this feature also implies ability to create a
changset and propagate as separated steps. Yet, svk is listed "Same as
subversion." So, I don't really know what this support of changesets
really means.
>
> Hmmm... now that you stated that possibility I see how this wording can
> refer to it. Nevertheless it is irrelevant to the criterion discussed;
Agreed.
>
> > > scm> <section id="tracking_uncommited_changes">
> > > scm> <title>Tracking Uncommited Changes</title>
> > > scm> <expl>
> > > scm> Does the software have an ability to track the changes in the
> > > scm> working copy that were not yet committed to the repository?
> > > scm> </expl>
> > >
> > > This also should be made more clean. Does it mean for example ability
> > > to tell which files have changed, or ability to diff working copy to
> > > either last comitted changes, or to any revision available in repository?
> >
> > Also, ability to diff one or more specified files in the working copy to
> > some specified revision.
>
> Right.
>
> I'm not sure now if "Tracking Uncommitted Changes" is a good name for
> this feature / criterion, but I don't have definite idea for change...
Actually, I don't like this name either. In particular, the word
"tracking". Perhaps, "Showing Uncommitted Changes" would be a better
name. Yet, ability to show diff between the working copy as some
arbitrary version should be listed as a separate feature.
> > So, I am not sure were the word "Medium" came from.
>
> Backward compatibility^W^W Old impressions die hard, I would guess...
> And the meme that git documentation is not user friendly is hard to
> fight.
Yes. And, frankly, earlier versions of it were not very user friendly.
When you looked at some porcelain command and it referred you to
plumbing to see what options it takes, that gave very bad impression.
Now, this and similar shortcomings are corrected, but as you said the
old impressions die hard...
Dmitry
^ permalink raw reply
* TopGit: how to deal with upstream inclusion
From: martin f krafft @ 2008-09-14 20:30 UTC (permalink / raw)
To: Petr Baudis, git
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]
Hi Petr, hi Gits,
So the Debian topgit package used to have a branch fixes/destdir to
make the Makefile distro-friendly. TopGit 0.3 has integrated this,
thus obsoleting the fixes/destdir branch.
I thought the way to handle this would be to simply delete the
TopGit branch, but of course that breaks everything, e.g.:
lapse:..t/topgit|debian/locations|% tg update
tg: fatal: some dependencies are missing: fixes/destdir
I now we had a recent discussion about how to remove branches, and
that there's basically no way to do this. In the discussion,
upstream inclusion was listed as one of the instances when this
wouldn't be needed, but that refers to upstream pulling/am'ing my
commits, not implementing the same functionality differently.
How do I retire the fixes/destdir branch? Do I manually remove the
dependency from depending branches?
Thanks,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"one should never allow one's mind
and one's foot to wander at the same time."
-- edward perkins (yes, the librarian)
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [StGit PATCH] Do not crash if a patch log ref is missing
From: Catalin Marinas @ 2008-09-14 21:01 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080914080839.GA30664@diana.vm.bytemark.co.uk>
On 14/09/2008, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-09-12 22:54:58 +0100, Catalin Marinas wrote:
>
> > Since we'll get rid of the individual patch logs, StGit should
> > ignore if such a ref is missing when deleting the compatibility
> > patch files.
>
>
> I agree this is a good idea from a robustness perspective. Did you
> encounter a case where the deletion actually failed?
Yes, I was deleting some older patches and it happened for one of them
not to have a log reference. It left the stack in a pretty undefined
state (and used the stable StGit to delete the rest of the patches as
it is more tolerant :-)).
--
Catalin
^ permalink raw reply
* Re: TopGit: how to deal with upstream inclusion
From: Petr Baudis @ 2008-09-14 21:03 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20080914203043.GA4872@lapse.rw.madduck.net>
Hi,
On Sun, Sep 14, 2008 at 09:30:43PM +0100, martin f krafft wrote:
> So the Debian topgit package used to have a branch fixes/destdir to
> make the Makefile distro-friendly. TopGit 0.3 has integrated this,
> thus obsoleting the fixes/destdir branch.
>
> I thought the way to handle this would be to simply delete the
> TopGit branch, but of course that breaks everything, e.g.:
>
> lapse:..t/topgit|debian/locations|% tg update
> tg: fatal: some dependencies are missing: fixes/destdir
>
> I now we had a recent discussion about how to remove branches, and
> that there's basically no way to do this. In the discussion,
> upstream inclusion was listed as one of the instances when this
> wouldn't be needed, but that refers to upstream pulling/am'ing my
> commits, not implementing the same functionality differently.
upstream should never pull TopGit branches! They have ugly history and
contain .topdeps and .topmsg junk files. That's what tg patch and
tg export is there for. :-)
If upstream applies the changes, the branch becomes unnecessary and
then it is ok to have some command like 'tg depend rm' to get rid of the
branch, since the *changes* aren't going away, thus we don't need to
create any "revert commits", which is the real issue with the general
'tg depend rm' command.
> How do I retire the fixes/destdir branch? Do I manually remove the
> dependency from depending branches?
Almost. The real 'tg depend rm' (or maybe rather, 'tg depend fold' as
in "this topic branch got folded to that branch") command would be
slightly more complicated, I think, in order to ensure that no
mysterious leftovers of the retired patch are lurking in your patch
tree. Assuming
tg depend fold RETIRED VANILLA
(i) Take the RETIRED _base_ branch
(ii) Merge in VANILLA
(iii) Merge in RETIRED head branch with -s ours
(iv) Now we have a commit that contains RETIRED topic branch, but with
the RETIRED's changes taken from VANILLA instead of RETIRED
(v) Merge this into the base of your current branch
(vi) Merge base to the head of your current branch, replacing RETIRED
with VANILLA (if not already there) in the .topdeps
(vii) You do not have to add VANILLA if you depend on it recursively
and ran tg update before to get it from your dependencies
Maybe in your case this could be even simpler but this should be the
general process. Does that sound right?
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [StGit PATCH] Autosign newly created patches
From: Catalin Marinas @ 2008-09-14 21:05 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080914083728.GB30664@diana.vm.bytemark.co.uk>
2008/9/14 Karl Hasselström <kha@treskal.com>:
> On 2008-09-12 22:55:56 +0100, Catalin Marinas wrote:
>
>> This patch adds the autosign configuration variable which is checked
>> by the "new" command to automatically sign the patch message.
>
> Sounds useful. I have a sign-off command in my .emacs, but I expect
> this would be useful for those who don't.
I use emacs for writing code but not that much for stgit commands (I
prefer the shell).
>> BTW, what happened to the patchdescr.tmpl file? It doesn't seem to
>> be used anymore, however one can save a template file
>
> I don't know. I don't use it myself, so it's perfectly possible that
> I've broken it without noticing, seeing as there is no test suite
> coverage ...
There isn't a test but the command description suggests that
patchdesr.tmpl file will be used if present.
Should we keep this feature? The only case where I was using it was
for automatic signed-off-by line.
--
Catalin
^ permalink raw reply
* Re: Git at Better SCM Initiative comparison of VCS (long)
From: Shawn O. Pearce @ 2008-09-14 21:06 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Jakub Narebski, git, Alexey Mahotkin
In-Reply-To: <20080914194802.GH28210@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Sun, Sep 14, 2008 at 07:48:05PM +0200, Jakub Narebski wrote:
> >
> > [...] if it is possible
> > using current hooks infrastructure to restrict changes coming from
> > some account in such a way as to allow it only if all changes are
> > restricted to specified directory.
>
> I believe the update hook should be able to do that. You have oldrev and
> newrev, so you can run "git diff --name-only oldrev newrev" and see what
> files are going to change. And then verify that the user has the write
> access to this directories or files.
>
> I have not tried it yet, and I don't think we have a ready example of
> how to do that, but I believe that the example of the update hook that
> restricts user access based on the target branch can be used as a
> starting point.
contrib/hooks/update-paranoid can do both branch and file path
level restrictions. I used it at my prior day-job to prevent some
accidental changes from folks who didn't usually need to modify
certain parts of the repository.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 16/16] ls-files: add --overlay option
From: Jakub Narebski @ 2008-09-14 21:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-17-git-send-email-pclouds@gmail.com>
I will comment only on the Documentation part...
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Narrow checkout mode introduces an interesting case: some files
> are not to be checked out (marked CE_NO_CHECKOUT in index) but still
> exist in working directory. Those files will be ignored by Git unless
> explicitly specified. In ClearCase, these files are called "eclipsed".
> I would call them "overlay" for now. Any better term is welcome.
"un-un-checked-out"? Just kidding. "not needed", "unneeded",...
ah, I know, perhaps "unwanted"? Or "orphaned" ("abandoned")?
[...]
> --- a/Documentation/git-ls-files.txt
> +++ b/Documentation/git-ls-files.txt
[...]
> +--overlay::
> + Show files that are marked no-checkout but exist in working directory.
> +
Shouldn't this be another letter in status mode? What about files
which should be not checked-out, but are modified? Or for simplicity
it is just list of files which have "no checkout" bit set, but are
present in working directory (and are not unmerged?)?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Jakub Narebski @ 2008-09-14 21:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1221397685-27715-16-git-send-email-pclouds@gmail.com>
I will comment only on the documentation...
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> These options include:
>
> --full: return to full checkout (default)
> --path: narrow checkout to some areas according to given spec
> --add-path/--remove-path: adjust current narrow checkout
Hmmm... I'm not sure if such formatting of commit message, with
body being not independent on the subject (first line of commit
message) is a good idea.
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
[...]
> +--full::
> + Quit narrow checkout mode. Return to full checkout.
> +
> +--path=<narrow_spec>::
> + Re-apply new narrow spec on current working directory to
> + form new checkout area.
> +
> +--add-path=<narrow_spec>::
> + Checkout more areas specified by narrow spec to current
> + checkout area.
> +
> +--remove-path=<narrow_spec>::
> + Narrow checkout area by removing files specified by narrow spec
> + from current checkout area. This operation will fail if there
> + is unmerged or modified files in the removing areas.
Subversion from version 1.5 supports something called "Sparse directories",
http://blogs.open.collab.net/svn/2007/06/sparse-director.html (as pointed
out by Bjorn Steinbrink (doener_) on #git). Subversion has the following
options for 'svn checkout':
-N::
--non-recursive::
Checkout only the main directory of the trunk and not the
sub-directories
--depth=empty::
Updates will not pull in any files or subdirectories not
already present.
--depth=files::
Updates will pull in any files not already present,
but not subdirectories.
--depth=immediates::
Updates will pull in any files or subdirectories not
already present; the subdirectories will have depth=empty.
--depth=infinity::
Updates will pull in any files or subdirectories not
already present; the subdirectories will have depth=infinity.
Equivalent to today's default update behavior.
I'm not sure if those ways of limiting are worth implementing, but
I guess that they are at least worth thinking about.
> +Narrow checkout
> +---------------
> +
> +Normally when you do checkout a branch, your working directory
> +will be fully populated. In some situations, you just need to
> +work on certain files, no full checkout is required. Narrow
> +checkout is a mode that limits checkout area according to your
> +rules.
Perhaps s/required/needed/?
> +
> +Because narrow checkout uses new index format, it will be
> +incompatible with git prior to 1.6.0. In order to make your
> +working directory work with those versions, you can use `git
> +checkout --full` to return to normal mode (and compatible index
> +format).
Very nice to have those compatibility concerns mentioned upfront.
In short: new feature, wouldn't work with git prior to 1.6.0.
I hope that nobody mistakes _working_ with repository with
partial / sparse / narrow checkout, which requires >= 1.6.0,
with being able to clone / fetch such repository, where there
are no limitations, contrary for example to what was for submodule
support.
> +
> +Narrow works by applying your rules to the index, marking which
> +file you need and which file you need not. Modified/Unmerged
> +files cannot be marked unneeded. Unnecessary files will be
> +removed from working directory. Note that after this step,
> +removed files can still be added to working directory when they
> +are needed by any git command. For example, when you have a merge
> +conflict, conflicted files will be checked out on working
> +directory and will no longer be marked "unneeded".
This paragraph I think need some more love...
So the "checkout rules" are meant to mark which paths are "wanted"
or "needed", and we would like to have in the checkout, and which
files are "unwanted" or "not needed" ("unneeded"?) and we want to
not have them present in working directory; something akin to accept
and deny rules, isn't it?
What are the rules, does all files except those marked explicitely
as needed are unneeded, or do you have to first mark all files as
unneeded?
How would the following table look like:
working directory || needed | not needed |
----------------------------------------------------
file is absent || checkout | no change |
file is present || no change | removed |
file is modified || conflict | conflict? |
> +
> +New files after merges will always be "needed". You can also
> +apply rules when switching branches to avoid unwanted new files.
Does it mean that if merge brings some new files, then those
files would be "needed" (without "no checkout" bit)?
What does it mean this sentence about switching branches:
how does partial/sparse/narrow checkout rules change when
switching to other branch (which, like 'html' and 'todo'
branches in git repository, can be completely unrelated)?
> +
> +Files that are marked "no-checkout" will be treated like entries
> +with "assume-unchanged bit" (see linkgit:git-update-index[1]). In
> +short, Git will never look for those files in working directory
> +no matter whether they exist in working directory.
Perhaps add that they would be marked with "no checkout" bit, and
refer to --no-checkout flag of git-update-index? I'm not sure here
about that...
> +
> +You can apply your rules at once with --path option, or do it
> +incrementally with --add-path and --remove-path.
Nice.
> +
> +Narrow spec will be used to specify how you want to narrow your
> +checkout. It is a list of pathspecs separated by colons. Each
> +patchspec specifies what files should be checked out on working
> +directory. Pathspec can contain wildcards and is relative to
> +current working directory. Usually asterisk (*) does not match
> +slashes. If a pathspec is prefixed by a plus sign (+), then
> +any asterisk will match anything, even slashes.
First, does this mean that you can specify paths containing colons
(':') only using --add-path and --remove-path, or does it mean that
you cannot specify paths containg colon ':' (which should be rare)
at all as checkout limiter / checkout narrowing rule?
Second, wouldn't it be better to use '**' to match also '/'?
Changing meaning of '*' using per-path flag seems a bit bad.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Catalin Marinas @ 2008-09-14 21:19 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080914085118.GC30664@diana.vm.bytemark.co.uk>
2008/9/14 Karl Hasselström <kha@treskal.com>:
> On 2008-09-12 23:01:27 +0100, Catalin Marinas wrote:
>
>> This patch converts the sink command to use stgit.lib. The behaviour
>> is also changed slightly so that it only allows to sink a set of
>> patches if there are applied once,
>
> "if they are applied"?
Without the spelling mistakes - "if there are applied patches (ones)".
Of course, unapplied patches can be sinked but when there are no
applied patches, it is equivalent to a push and decided to make it
fail.
>> I'm not sure about the conflict resolution. In this implementation,
>> if a conflict happens, the transaction is aborted. In case we allow
>> conflicts, I have to dig further on how to implement it with the new
>> transaction mechanism (I think "delete" does this).
>
> goto does it too. The docstring of the StackTransaction class explains
> how it works (if it doesn't, we need to improve it):
I wasn't used to reading documentation in StGit files :-). Thanks for
the info, I'll repost. I'll make the default behaviour to cancel the
transaction and revert to the original state unless an option is given
to allow conflicts.
>> An additional point - the transaction object supports functions like
>> pop_patches and push_patch. Should we change them for consistency
>> and simplicity? I.e., apart from current pop_patches with predicate
>> add functions that support popping a list or a single patch. The
>> same goes for push_patch.
>
> The current set of functions made sense from an implementation
> perspective. But you are right that other variants would be helpful
> for some callers.
I can see calls to pop_patches(lambda pn: pn in patch_list). I think
we could have a helper for this. I'll try to post a patch sometime
next week.
--
Catalin
^ permalink raw reply
* [PATCH] git-svn: factor out svnserve test code for later use
From: Alec Berryman @ 2008-09-14 21:14 UTC (permalink / raw)
To: git, Eric Wong; +Cc: Alec Berryman
In-Reply-To: <1221426856-2652-1-git-send-email-alec@thened.net>
Signed-off-by: Alec Berryman <alec@thened.net>
---
t/lib-git-svn.sh | 17 +++++++++++++++++
t/t9113-git-svn-dcommit-new-file.sh | 14 +-------------
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index c526eed..67c431d 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -138,3 +138,20 @@ close $wr or die $!;
close $rd or die $!;
EOF
}
+
+require_svnserve () {
+ if test -z "$SVNSERVE_PORT"
+ then
+ say 'skipping svnserve test. (set $SVNSERVE_PORT to enable)'
+ test_done
+ exit
+ fi
+}
+
+start_svnserve () {
+ svnserve --listen-port $SVNSERVE_PORT \
+ --root "$rawsvnrepo" \
+ --listen-once \
+ --listen-host 127.0.0.1 &
+}
+
diff --git a/t/t9113-git-svn-dcommit-new-file.sh b/t/t9113-git-svn-dcommit-new-file.sh
index 250c530..e9b6128 100755
--- a/t/t9113-git-svn-dcommit-new-file.sh
+++ b/t/t9113-git-svn-dcommit-new-file.sh
@@ -12,19 +12,7 @@ test_description='git svn dcommit new files over svn:// test'
. ./lib-git-svn.sh
-if test -z "$SVNSERVE_PORT"
-then
- say 'skipping svnserve test. (set $SVNSERVE_PORT to enable)'
- test_done
- exit
-fi
-
-start_svnserve () {
- svnserve --listen-port $SVNSERVE_PORT \
- --root "$rawsvnrepo" \
- --listen-once \
- --listen-host 127.0.0.1 &
-}
+require_svnserve
test_expect_success 'start tracking an empty repo' '
svn mkdir -m "empty dir" "$svnrepo"/empty-dir &&
--
1.6.0.2.231.gfc858
^ permalink raw reply related
* [PATCH] git-svn: Always create a new RA when calling do_switch for svn://
From: Alec Berryman @ 2008-09-14 21:14 UTC (permalink / raw)
To: git, Eric Wong
This was reported as Debian bug #464713. An example repository can be
found at svn://svn.debian.org/chinese/packages/lunar-applet. When I try
to clone it with 1.6.0.2.229.g1293c or 1.5.6.5, both using 1.5.1
libraries, I see the following:
r158 = 1107cff6309c979751e0841d40b9e2e471694b26 (git-svn@159)
M debian/changelog
M debian/rules
r159 = 010d0b481753bd32ce0255ce433d63e14114d3b6 (git-svn@159)
Found branch parent: (git-svn) 010d0b481753bd32ce0255ce433d63e14114d3b6
Following parent with do_switch
Malformed network data: Malformed network data at /home/alec/local/git/libexec/git-core//git-svn line 2360
It looks like the user made several commits and decided to undo them by
removing the directory and copying an older version in its place.
This appears to only affect access via svn:// and svn+ssh://; I tried
with file:// but not with http://.
The first patch is a minor refactoring of some test code, and the second
one actually fixes the issue for me.
^ permalink raw reply
* [PATCH] git-svn: Always create a new RA when calling do_switch for svn://
From: Alec Berryman @ 2008-09-14 21:14 UTC (permalink / raw)
To: git, Eric Wong; +Cc: Alec Berryman
In-Reply-To: <1221426856-2652-2-git-send-email-alec@thened.net>
Not doing so caused the "Malformed network data" error when a directoy
was deleted and replaced with a copy from an older version.
Signed-off-by: Alec Berryman <alec@thened.net>
---
git-svn.perl | 25 ++--
...126-git-svn-follow-deleted-readded-directory.sh | 22 ++
t/t9126/follow-deleted-readded.dump | 201 ++++++++++++++++++++
3 files changed, 235 insertions(+), 13 deletions(-)
create mode 100755 t/t9126-git-svn-follow-deleted-readded-directory.sh
create mode 100644 t/t9126/follow-deleted-readded.dump
diff --git a/git-svn.perl b/git-svn.perl
index 88066c9..af8279a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4010,20 +4010,19 @@ sub gs_do_switch {
my $old_url = $full_url;
$full_url .= '/' . escape_uri_only($path) if length $path;
my ($ra, $reparented);
- if ($old_url ne $full_url) {
- if ($old_url !~ m#^svn(\+ssh)?://#) {
- SVN::_Ra::svn_ra_reparent($self->{session}, $full_url,
- $pool);
- $self->{url} = $full_url;
- $reparented = 1;
- } else {
- $_[0] = undef;
- $self = undef;
- $RA = undef;
- $ra = Git::SVN::Ra->new($full_url);
- $ra_invalid = 1;
- }
+
+ if ($old_url =~ m#^svn(\+ssh)?://#) {
+ $_[0] = undef;
+ $self = undef;
+ $RA = undef;
+ $ra = Git::SVN::Ra->new($full_url);
+ $ra_invalid = 1;
+ } elsif ($old_url ne $full_url) {
+ SVN::_Ra::svn_ra_reparent($self->{session}, $full_url, $pool);
+ $self->{url} = $full_url;
+ $reparented = 1;
}
+
$ra ||= $self;
$url_b = escape_url($url_b);
my $reporter = $ra->do_switch($rev_b, '', 1, $url_b, $editor, $pool);
diff --git a/t/t9126-git-svn-follow-deleted-readded-directory.sh b/t/t9126-git-svn-follow-deleted-readded-directory.sh
new file mode 100755
index 0000000..edec640
--- /dev/null
+++ b/t/t9126-git-svn-follow-deleted-readded-directory.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Alec Berryman
+
+test_description='git svn fetch repository with deleted and readded directory'
+
+. ./lib-git-svn.sh
+
+# Don't run this by default; it opens up a port.
+require_svnserve
+
+test_expect_success 'load repository' '
+ svnadmin load -q "$rawsvnrepo" < "$TEST_DIRECTORY"/t9126/follow-deleted-readded.dump
+ '
+
+test_expect_success 'fetch repository' '
+ start_svnserve &&
+ git svn init svn://127.0.0.1:$SVNSERVE_PORT &&
+ git svn fetch
+ '
+
+test_done
diff --git a/t/t9126/follow-deleted-readded.dump b/t/t9126/follow-deleted-readded.dump
new file mode 100644
index 0000000..19da5d1
--- /dev/null
+++ b/t/t9126/follow-deleted-readded.dump
@@ -0,0 +1,201 @@
+SVN-fs-dump-format-version: 2
+
+UUID: 1807dc6f-c693-4cda-9710-00e1be8c1f21
+
+Revision-number: 0
+Prop-content-length: 56
+Content-length: 56
+
+K 8
+svn:date
+V 27
+2008-09-14T19:53:13.006748Z
+PROPS-END
+
+Revision-number: 1
+Prop-content-length: 111
+Content-length: 111
+
+K 7
+svn:log
+V 12
+Create trunk
+K 10
+svn:author
+V 4
+alec
+K 8
+svn:date
+V 27
+2008-09-14T19:53:13.239689Z
+PROPS-END
+
+Node-path: trunk
+Node-kind: dir
+Node-action: add
+Prop-content-length: 10
+Content-length: 10
+
+PROPS-END
+
+
+Revision-number: 2
+Prop-content-length: 119
+Content-length: 119
+
+K 7
+svn:log
+V 20
+Create trunk/project
+K 10
+svn:author
+V 4
+alec
+K 8
+svn:date
+V 27
+2008-09-14T19:53:13.548860Z
+PROPS-END
+
+Node-path: trunk/project
+Node-kind: dir
+Node-action: add
+Prop-content-length: 10
+Content-length: 10
+
+PROPS-END
+
+
+Revision-number: 3
+Prop-content-length: 111
+Content-length: 111
+
+K 7
+svn:log
+V 12
+add new file
+K 10
+svn:author
+V 4
+alec
+K 8
+svn:date
+V 27
+2008-09-14T19:53:15.433630Z
+PROPS-END
+
+Node-path: trunk/project/foo
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 4
+Text-content-md5: d3b07384d113edec49eaa6238ad5ff00
+Content-length: 14
+
+PROPS-END
+foo
+
+
+Revision-number: 4
+Prop-content-length: 116
+Content-length: 116
+
+K 7
+svn:log
+V 17
+change foo to bar
+K 10
+svn:author
+V 4
+alec
+K 8
+svn:date
+V 27
+2008-09-14T19:53:17.339884Z
+PROPS-END
+
+Node-path: trunk/project/foo
+Node-kind: file
+Node-action: change
+Text-content-length: 4
+Text-content-md5: c157a79031e1c40f85931829bc5fc552
+Content-length: 4
+
+bar
+
+
+Revision-number: 5
+Prop-content-length: 114
+Content-length: 114
+
+K 7
+svn:log
+V 15
+don't like that
+K 10
+svn:author
+V 4
+alec
+K 8
+svn:date
+V 27
+2008-09-14T19:53:19.335001Z
+PROPS-END
+
+Node-path: trunk/project
+Node-action: delete
+
+
+Revision-number: 6
+Prop-content-length: 110
+Content-length: 110
+
+K 7
+svn:log
+V 11
+reset trunk
+K 10
+svn:author
+V 4
+alec
+K 8
+svn:date
+V 27
+2008-09-14T19:53:19.845897Z
+PROPS-END
+
+Node-path: trunk/project
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 4
+Node-copyfrom-path: trunk/project
+
+
+Revision-number: 7
+Prop-content-length: 113
+Content-length: 113
+
+K 7
+svn:log
+V 14
+change to quux
+K 10
+svn:author
+V 4
+alec
+K 8
+svn:date
+V 27
+2008-09-14T19:53:21.367947Z
+PROPS-END
+
+Node-path: trunk/project/foo
+Node-kind: file
+Node-action: change
+Text-content-length: 5
+Text-content-md5: d3b07a382ec010c01889250fce66fb13
+Content-length: 5
+
+quux
+
+
--
1.6.0.2.231.gfc858
^ permalink raw reply related
* Re: Git at Better SCM Initiative comparison of VCS (long)
From: Jakub Narebski @ 2008-09-14 21:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dmitry Potapov, git, Alexey Mahotkin
In-Reply-To: <20080914210648.GB26608@spearce.org>
On Sun, 14 Sep 2008, Shawn O. Pearce wrote:
> Dmitry Potapov <dpotapov@gmail.com> wrote:
>> On Sun, Sep 14, 2008 at 07:48:05PM +0200, Jakub Narebski wrote:
>>>
>>> [...] if it is possible
>>> using current hooks infrastructure to restrict changes coming from
>>> some account in such a way as to allow it only if all changes are
>>> restricted to specified directory.
>>
>> I believe the update hook should be able to do that. You have oldrev and
>> newrev, so you can run "git diff --name-only oldrev newrev" and see what
>> files are going to change. And then verify that the user has the write
>> access to this directories or files.
>>
>> I have not tried it yet, and I don't think we have a ready example of
>> how to do that, but I believe that the example of the update hook that
>> restricts user access based on the target branch can be used as a
>> starting point.
>
> contrib/hooks/update-paranoid can do both branch and file path
> level restrictions. I used it at my prior day-job to prevent some
> accidental changes from folks who didn't usually need to modify
> certain parts of the repository.
Could you then update contrib/hooks/update-paranoid documentation?
It talks only about branch level restrictions (created, delete,
fast-forward, forced update for a given ref class).
Thanks in advance
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git at Better SCM Initiative comparison of VCS (long)
From: Jakub Narebski @ 2008-09-15 0:37 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Alexey Mahotkin
In-Reply-To: <20080914194802.GH28210@dpotapov.dyndns.org>
On Sun, 14 Sep 2008, Dmitry Potapov wrote:
> On Sun, Sep 14, 2008 at 07:48:05PM +0200, Jakub Narebski wrote:
> > > Another thing here is that "git commit" is local, so I am not sure
> > > if this question includes network operations...
> >
> > Well, I think this session would be better titled "Atomic Operations"
> > or just "Atomicity". Although I'm not sure if for example in Git
> > all operations are atomic under all conditions...
>
> I believe that all git basic operations are atomic. In fact, you either
> got a new revision with new SHA-1 or don't. Aborting operation may
> leave some dangling objects, but it is okay, because they will be
> garbage collected later. But I am not sure about additional utilities
> such as git-svn. Git-svn uses rebase as it dcommits, being interrupted,
> it may leave you in some strange state. It is possible to recover but
> it may be not obvious for newbies. Other than that, I think everything
> is very resilient to any interruption.
I was thinking here about long-lasting and multiple-parts operations
like for example git-clone. Nevertheless we would never be in
inconsistent state.
> > > So, perhaps, it should be two separate points:
> > > - ability to preserve history of rename (with detail clarification
> > > of what it means)
> > > - ability to show renames in the project history
> >
> > That are points '1' and '2' on my list, perhaps stated bit differently:
> > showing renames in full history / history of project as whole, and
> > following history of a single file across renames.
>
> I did not mean '1' and '2' as priorities, but that it is slightly
> different features and both can be titled as support of renaming.
I didn't mean '1' and '2' as priorities; they are more or less equal,
although I would say that '1' might be prerequisite to '2'. '0' is
however a base which must be satisfied for tool to be named to have
"rename support".
> > >
> > > Git tracks content rather than file-ids, and therefore it uses heuristics
> > > for rename detection. This approach has an advantage of being able to
> > > preserve history for code lines between files, which usually happens much
> > > more often than file renaming.
> >
> > I would rather write
> >
> > Renames are supported for most practical purposes[1]. By design Git
> > does heuristic <i>rename detection</i> (based on similarity score of
> > pathnames and file contents), instead of doing rename tracking (which
> > usually is based on some kind of file-ids). This approach allows for
> > more generic content tracking of code movement (which usually happens
> > much often than wholesame file renaming), e.g. in "git blame -C -C".
>
> Sounds good to me. Perhaps, I would drop '(which usually... file-ids)'
> to make the sentence a bit shorter.
O.K.
(But I would wait a bit for final proposal, with sending patch for
scm-comparison.xml to Alexey and Shlomi.)
> > > > scm> <section id="tracking_uncommited_changes">
> > > > scm> <title>Tracking Uncommited Changes</title>
> > > > scm> <expl>
> > > > scm> Does the software have an ability to track the changes in the
> > > > scm> working copy that were not yet committed to the repository?
> > > > scm> </expl>
> > > >
> > > > This also should be made more clean. Does it mean for example ability
> > > > to tell which files have changed, or ability to diff working copy to
> > > > either last comitted changes, or to any revision available in repository?
> > >
> > > Also, ability to diff one or more specified files in the working copy to
> > > some specified revision.
> >
> > Right.
> >
> > I'm not sure now if "Tracking Uncommitted Changes" is a good name for
> > this feature / criterion, but I don't have definite idea for change...
>
> Actually, I don't like this name either. In particular, the word
> "tracking". Perhaps, "Showing Uncommitted Changes" would be a better
> name. Yet, ability to show diff between the working copy as some
> arbitrary version should be listed as a separate feature.
I don't have good name either. It is <something> about Uncommitted Changes.
Dealing with, or support for, or something...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git User's Survey 2008 partial summary, part 5 - other SCM
From: david @ 2008-09-15 3:39 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, git
In-Reply-To: <fcaeb9bf0809140345n11d41430ma9b4096c66776b0c@mail.gmail.com>
On Sun, 14 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> On 9/12/08, Jakub Narebski <jnareb@gmail.com> wrote:
>> 15) Do you miss features in git that you know from other SCMs?
>> If yes, what features are these (and from which SCM)?
>> (Open ended text - Essay)
>>
>> Total respondents 1046 (some/many of them wrote 'no')
>> skipped this question 1249
>>
>> This is just a very quick summary, based on a first few pages of
>> responses, Full analysis is I think best left for after closing the
>> survey, because I think this would be a lot of work...
>>
>> So here is preliminary list, or rather beginning of one:
>> * sparse/partial checkout and clone (e.g. Perforce)
>
> Have not read the survey result, but do you recall what is the most
> used term for sparse/partial checkout? What SCMs do sparse/partial
> checkout? I think it could be usable as it is now in my
> will-be-sent-again series, but I don't really know how people want it
> to from that.
the most common use-case is people who want to follow a project but (at
least think that they) don't need the history. so they want to save
time/bandwideth/disk space by not downloading things they don't need.
David Lang
^ permalink raw reply
* [PATCH] Modifying RCS keywords prevents submitting to p4 from git due to missing hunks. Optional shrinking of RCS keywords in git-p4. New option git-p4.kwstrip set to true or false controls the behavior
From: Dhruva Krishnamurthy @ 2008-09-15 4:16 UTC (permalink / raw)
To: GIT SCM <git@vger.kernel.org>; Junio C Hamano; +Cc: Dhruva Krishnamurthy
Signed-off-by: Dhruva Krishnamurthy <dhruva@ymail.com>
---
contrib/fast-import/git-p4 | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2216cac..ac8b7f7 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -16,6 +16,9 @@ from sets import Set;
verbose = False
+# Handling of RCS keyowrds. To ensure backward compatibility, the default
+# is to strip keywords. Default behavior is controlled here
+kwstrip = True
def p4_build_cmd(cmd):
"""Build a suitable p4 command line.
@@ -975,7 +978,9 @@ class P4Sync(Command):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
continue
- if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
+ if not kwstrip:
+ pass
+ elif stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
@@ -1850,6 +1855,16 @@ def main():
(cmd, args) = parser.parse_args(sys.argv[2:], cmd);
global verbose
verbose = cmd.verbose
+
+ global kwstrip
+ kwval = gitConfig("git-p4.kwstrip")
+ if len(kwval) > 0:
+ kwval = kwval.lower();
+ if kwval == "false":
+ kwstrip = False
+ elif kwval == "true":
+ kwstrip = True
+
if cmd.needsGit:
if cmd.gitdir == None:
cmd.gitdir = os.path.abspath(".git")
--
1.6.0.1.454.g63d55
^ permalink raw reply related
* bad links on git homepage
From: david @ 2008-09-15 4:33 UTC (permalink / raw)
To: git
the links on the git homepage to download the 1.6.0.2 tarballs link to
kernel.org/... when they need to link to www.kernel.org
David Lang
^ permalink raw reply
* Re: git+ssh using 'plink' on windows
From: Edward Z. Yang @ 2008-09-15 4:53 UTC (permalink / raw)
To: git; +Cc: GIT SCM
In-Reply-To: <206914.98935.qm@web95012.mail.in2.yahoo.com>
This mailing list post may be of interest to you:
http://www.mail-archive.com/msysgit@googlegroups.com/msg00977.html
^ permalink raw reply
* Re: git+ssh using 'plink' on windows
From: Edward Z. Yang @ 2008-09-15 4:53 UTC (permalink / raw)
To: git
In-Reply-To: <206914.98935.qm@web95012.mail.in2.yahoo.com>
This mailing list post may be of interest to you:
http://www.mail-archive.com/msysgit@googlegroups.com/msg00977.html
^ permalink raw reply
* [PATCH] Optional shrinking of RCS keywords in git-p4
From: Dhruva Krishnamurthy @ 2008-09-15 5:58 UTC (permalink / raw)
To: GIT SCM; +Cc: Junio C Hamano, Dhruva Krishnamurthy
Modifying RCS keywords prevents submitting to p4 from git due to missing hunks.
New option git-p4.kwstrip set to true or false controls the behavior.
Signed-off-by: Dhruva Krishnamurthy <dhruva@ymail.com>
---
contrib/fast-import/git-p4 | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2216cac..ac8b7f7 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -16,6 +16,9 @@ from sets import Set;
verbose = False
+# Handling of RCS keyowrds. To ensure backward compatibility, the default
+# is to strip keywords. Default behavior is controlled here
+kwstrip = True
def p4_build_cmd(cmd):
"""Build a suitable p4 command line.
@@ -975,7 +978,9 @@ class P4Sync(Command):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
continue
- if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
+ if not kwstrip:
+ pass
+ elif stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
@@ -1850,6 +1855,16 @@ def main():
(cmd, args) = parser.parse_args(sys.argv[2:], cmd);
global verbose
verbose = cmd.verbose
+
+ global kwstrip
+ kwval = gitConfig("git-p4.kwstrip")
+ if len(kwval) > 0:
+ kwval = kwval.lower();
+ if kwval == "false":
+ kwstrip = False
+ elif kwval == "true":
+ kwstrip = True
+
if cmd.needsGit:
if cmd.gitdir == None:
cmd.gitdir = os.path.abspath(".git")
--
1.6.0.1.454.g63d55
^ permalink raw reply related
* Re: [PATCH] Modifying RCS keywords prevents submitting to p4 from git due to missing hunks. Optional shrinking of RCS keywords in git-p4. New option git-p4.kwstrip set to true or false controls the behavior
From: dhruva @ 2008-09-15 6:02 UTC (permalink / raw)
To: sverre; +Cc: GIT SCM, Junio C Hamano
I had a real tough time configuring 'git send-email'. Looks like I finally have something working... I am still finding it tough to handle identity. I am figuring it out now by trial and error (with more errors) basis
-dhruva
----- Original Message ----
> From: Sverre Rabbelier <alturin@gmail.com>
> To: Dhruva Krishnamurthy <dhruva@ymail.com>
> Cc: "GIT SCM <git@vger.kernel.org>, Junio C Hamano" <gitster@pobox.com>
> Sent: Monday, 15 September, 2008 10:24:37 AM
> Subject: Re: [PATCH] Modifying RCS keywords prevents submitting to p4 from git due to missing hunks. Optional shrinking of RCS keywords in git-p4. New option git-p4.kwstrip set to true or false controls the behavior
>
> On Mon, Sep 15, 2008 at 06:16, Dhruva Krishnamurthy wrote:
> >
> > Signed-off-by: Dhruva Krishnamurthy
>
> I think something went wrong here, yes? The current title is way too
> long, and there is no commit message, perhaps you meant to put (part
> of) the title in the message instead?
>
> "[PATCH] Modifying RCS keywords prevents submitting to p4 from git due
> to missing hunks. Optional shrinking of RCS keywords in git-p4. New
> option git-p4.kwstrip set to true or false controls the behavior"
>
> --
> Cheers,
>
> Sverre Rabbelier
Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08..html/
^ 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