* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-14 19:33 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Stephen Boyd, Kirill Smelkov, Sverre Rabbelier, Junio C Hamano,
Shawn O. Pearce, git
In-Reply-To: <20091114144303.GA31540@neumann>
Hi Gábor,
SZEDER Gábor wrote:
> Why? Don't get overly creative here, the command
>
> . /path/to/git-completion.bash
>
> already does that, plus it fixes the merge strategy completion issue,
> and it's friendly enough for the users.
Sounds like a good approach. Squashing this in should get that
working again.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
In this patch, I assume the merge strategy list is not being cached
any more. Something like this would allow recovering from the merge
strategy completion issue, but the victim would have to notice what
went wrong first.
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 634941f..ae39373 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -495,6 +495,7 @@ __git_list_all_commands ()
done
}
+unset __git_all_commands
__git_compute_all_commands ()
{
: ${__git_all_commands=$(__git_list_all_commands)}
@@ -586,6 +587,7 @@ __git_list_porcelain_commands ()
done
}
+unset __git_porcelain_commands
__git_compute_porcelain_commands ()
{
__git_compute_all_commands
--
1.6.5.2
^ permalink raw reply related
* [PATCH] cvsserver doc: database generally can not be reproduced consistently
From: Matthew Ogilvie @ 2009-11-14 18:39 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
A regenerated git-cvsserver database is at risk of having different
CVS revision numbers from an incrementally updated database. Mention
this in the the documentation, and remove an erroneous statement
to the contrary.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Documentation/git-cvsserver.txt | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 785779e..99a7c14 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -182,10 +182,9 @@ Database Backend
----------------
'git-cvsserver' uses one database per git head (i.e. CVS module) to
-store information about the repository for faster access. The
-database doesn't contain any persistent data and can be completely
-regenerated from the git repository at any time. The database
-needs to be updated (i.e. written to) after every commit.
+store information about the repository to maintain consistent
+CVS revision numbers. The database needs to be
+updated (i.e. written to) after every commit.
If the commit is done directly by using `git` (as opposed to
using 'git-cvsserver') the update will need to happen on the
@@ -204,6 +203,18 @@ write so it might not be enough to grant the users using
'git-cvsserver' write access to the database file without granting
them write access to the directory, too.
+The database can not be reliably regenerated in a
+consistent form after the branch it is tracking has changed.
+Example: For merged branches, 'git-cvsserver' only tracks
+one branch of development, and after a 'git-merge' an
+incrementally updated database may track a different branch
+than a database regenerated from scratch, causing inconsistent
+CVS revision numbers. `git-cvsserver` has no way of knowing which
+branch it would have picked if it had been run incrementally
+pre-merge. So if you have to fully or partially (from old
+backup) regenerate the database, you should be suspicious
+of pre-existing CVS sandboxes.
+
You can configure the database backend with the following
configuration variables:
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH] Doc: mention the crlf attribute in config autocrlf section
From: Matthew Ogilvie @ 2009-11-14 18:35 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
The reverse reference has long existed, and the autocrlf description
was actually obsolete and wrong (saying only file content is used),
not just incomplete.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Documentation/config.txt | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1e2120..0dc6b12 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -169,9 +169,10 @@ core.autocrlf::
writing to the filesystem. The variable can be set to
'input', in which case the conversion happens only while
reading from the filesystem but files are written out with
- `LF` at the end of lines. Currently, which paths to consider
- "text" (i.e. be subjected to the autocrlf mechanism) is
- decided purely based on the contents.
+ `LF` at the end of lines. A file is considered
+ "text" (i.e. be subjected to the autocrlf mechanism) based on
+ the file's `crlf` attribute, or if `crlf` is unspecified,
+ based on the file's contents. See linkgit:gitattributes[5].
core.safecrlf::
If true, makes git check if converting `CRLF` as controlled by
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Raman Gupta @ 2009-11-14 17:27 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, trast, gitster
In-Reply-To: <20091114180123.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting Raman Gupta <rocketraman@fastmail.fm>
>
>> Ok, another dumb question: since you have now submitted a patch on top
>> of my patch, what is the proper etiquette for proceeding? Who
>> maintains this patch series until it is committed? Since your patch
>> applies on top of mine I can't really make any more changes without
>> affecting your patch right? I can't find any guidance in the
>> SubmittingPatches document.
>
> What usually happens is that we wait now.
>
> In this case we are in agreement that it is a good idea to apply
> both of our patches (mine was only repeating what Junio said in
> his comments), so if I were you, I would anticipate that Junio
> would apply both of them and start preparing incremental updates
> on top of them now, and send them when the patches appear in his
> 'pu' branch.
>
> Junio has gone quiet for the past few days; maybe he is too busy
> to read or respond to either of our patch. Instead of preparing
> the final text you write in the document in a patch format, it
> may be a better to bring up your ideas here and discuss them
> first. What changes do you have in mind? I think the new section
> now already is in a reasonable shape.
No specific changes -- it was a hypothetical question...
Cheers,
Raman
^ permalink raw reply
* Re: git svn fetch loses data
From: Sverre Rabbelier @ 2009-11-14 17:25 UTC (permalink / raw)
To: Victor Engmark; +Cc: git
In-Reply-To: <7d4f41f50911140907n285d72dcp7bbe802900f8bae5@mail.gmail.com>
Heya,
On Sat, Nov 14, 2009 at 18:07, Victor Engmark <victor.engmark@gmail.com> wrote:
> but at the end about half of the
> root directories are missing.
Can you be more specific, what is the layout of your repository and
which directories are missing?
/ -- trunk
-- branches
-- tags
-- thirdparty
-- private
If your repository looks like that, and 'thirdparty' and 'private' are
missing, that's because git svn assumes that you're only interested in
trunk, branches and tags by default.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* git svn fetch loses data
From: Victor Engmark @ 2009-11-14 17:07 UTC (permalink / raw)
To: git
Hi all,
I've been trying to move from Subversion to Git for a couple days now,
and I can't get git svn to get all my data. The progress so far is
explained at <http://l0b0.wordpress.com/2009/11/14/n-way-git-synchronization-with-extra-cheese/>.
git svn fetch doesn't report any errors, and goes through the entire
repository as regular as anything, but at the end about half of the
root directories are missing. Even the file modified by the last
commit is not there at all. Any ideas why this is?
--
Victor Engmark
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: SZEDER Gábor @ 2009-11-14 14:43 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Stephen Boyd, Kirill Smelkov, Sverre Rabbelier, Junio C Hamano,
Shawn O. Pearce, git
In-Reply-To: <20091114110141.GB1829@progeny.tock>
Hi,
On Sat, Nov 14, 2009 at 05:01:41AM -0600, Jonathan Nieder wrote:
> Stephen Boyd wrote:
>
> > I see a small problem, but it can be fixed in another patch. git
> > merge -s <TAB><TAB> the first time when you're not in a git
> > directory will make git merge -s <TAB><TAB> after never complete
> > correctly even in a git directory.
>
> Not good. I think the sanest thing to do is avoid caching the merge
> strategy list entirely. Listing merge strategies takes about 100 ms
> here, which is short enough not to be annoying.
>
> > I guess this become more serious
> > if git isn't in your path initially and you do git <TAB><TAB> and
> > then git becomes part of your path and you try again. Here you lose
> > porcelain completion. This is probably never going to happen though,
> > right?
>
> Right, if this happened to me I would not be too surprised. A similar
> problem occurs when someone installs a new git subcommand in the
> middle of a session. Starting a new session fixes the completion, but
> should the completion script do something to help people before then?
>
> It could provide a shell function with a slightly friendlier name than
> "__git_compute_porcelain_commands" for the user to invoke explicitly.
>
> It could retry "git help -a" each time completion was needed if it
> gave no results last time (i.e. use "${__git_all_commands:=" instead
> of "${__git_all_commands="). This would help with the missing git
> problem (which seems unusual), but not the missing git-svn.
>
> Maybe it could detect signs of user frustration (repeated attempts to
> complete the same thing?) and add to the frustration by silently
> fixing the cache.
Why? Don't get overly creative here, the command
. /path/to/git-completion.bash
already does that, plus it fixes the merge strategy completion issue,
and it's friendly enough for the users.
Best,
Gábor
^ permalink raw reply
* Re: GNU patch: new 2.6 release
From: Björn Gustavsson @ 2009-11-14 12:27 UTC (permalink / raw)
To: bug-patch; +Cc: git
In-Reply-To: <200911141117.29238.agruen@suse.de>
2009/11/14 Andreas Gruenbacher <agruen@suse.de>:
> Support for git's extended header lines for renames, copies, hashes, file
> modes would be great. I'll happily take patches or eventually implement it
> myself. Binary patches are not as high on my wish list, but feel free to send
> code.
Support for the other extended header lines would be useful for me too.
I might have a go at implementing them (and binary patches) at some
point in the future.
>> That would be very useful in a workflow when you work in git (and have some
>> binary files in the repository), but need to commit your finished work
>> into another VCS (such as Clearcase).
>
> Isn't there a better way to do this than with patches?
If there is a better way, I would be very interested in finding out what it is.
Feeding the output from 'git format-patch' to patch is the
best way I've had come up with yet. patch (given the '-g 1' option)
will automatically check out the files that are to be patched.
I have wrapped that in a simple script that retrieves the commit
comment from the patch and check in the files with that commit
comment.
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: gitk: Update Japanese translation
From: Paul Mackerras @ 2009-11-14 11:14 UTC (permalink / raw)
To: Mizar; +Cc: git, gitster
In-Reply-To: <d092a4360911060557v970753fn2294124aedda93ec@mail.gmail.com>
Mizar writes:
> The main changes are as follows.
> Several issues remain and is pending because there is no improvement.
> http://github.com/mizar/gitk/issues
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: disable checkout of remote branch
From: Paul Mackerras @ 2009-11-14 11:14 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <2e24e5b90911030800j22b00372r99a56c3f847a3644@mail.gmail.com>
Sitaram Chamarty writes:
> This prevents a lot of detached HEAD commits by new users.
>
> Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Fix "git gui blame" invocation when called from topdir
From: Paul Mackerras @ 2009-11-14 11:14 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git
In-Reply-To: <1257290501-21093-1-git-send-email-markus.heidelberg@web.de>
Markus Heidelberg writes:
> In this case "git rev-parse --git-dir" doesn't return an absolute path,
> but merely ".git", so the selected file has a relative path.
> The function make_relative then tries to make the already relative path
> relative, which results in a path like "../../../../Makefile" with as
> much ".." as the number of parts [pwd] consists of.
>
> This regression was introduced by commit 9712b81 (gitk: Fix bugs in
> blaming code, 2008-12-06), which fixed "git gui blame" when called from
> subdirs.
>
> This also fixes it for bare repositories.
>
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [gitk] [PATCH] 0/2 Merging master into dev
From: Paul Mackerras @ 2009-11-14 11:20 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Johannes Schindelin
In-Reply-To: <871vkbw7x2.fsf@users.sourceforge.net>
Pat Thoyts writes:
> I've merged the current changes for gitk master onto the dev branch
> and fixed some conflicts and then modified the default colour
> assignments for windows to use the system colours so that it will pick
> up the stock colours defined via the windows property pages.
>
> However, I'm not too certain how to post such a merge commit. Usually
> I do 'git format-patch -M' but in this case that emits all the commits
> that were merged. It looks like 'git show -p' is producing a merge
> patch so I am posting that for 1/2 and a normal patch for 2/2. If
> there is better way let me know and I will redo.
I don't think there is a way to send a merge commit by email. I think
you would have to put a repository somewhere with the merge in it and
invite me to pull it.
In any case, I have just merged the dev branch into the master branch
and then applied your second patch, and pushed out the result.
Paul.
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-14 11:01 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <4AFDC4F3.1050607@gmail.com>
Stephen Boyd wrote:
> I see a small problem, but it can be fixed in another patch. git
> merge -s <TAB><TAB> the first time when you're not in a git
> directory will make git merge -s <TAB><TAB> after never complete
> correctly even in a git directory.
Not good. I think the sanest thing to do is avoid caching the merge
strategy list entirely. Listing merge strategies takes about 100 ms
here, which is short enough not to be annoying.
> I guess this become more serious
> if git isn't in your path initially and you do git <TAB><TAB> and
> then git becomes part of your path and you try again. Here you lose
> porcelain completion. This is probably never going to happen though,
> right?
Right, if this happened to me I would not be too surprised. A similar
problem occurs when someone installs a new git subcommand in the
middle of a session. Starting a new session fixes the completion, but
should the completion script do something to help people before then?
It could provide a shell function with a slightly friendlier name than
"__git_compute_porcelain_commands" for the user to invoke explicitly.
It could retry "git help -a" each time completion was needed if it
gave no results last time (i.e. use "${__git_all_commands:=" instead
of "${__git_all_commands="). This would help with the missing git
problem (which seems unusual), but not the missing git-svn.
Maybe it could detect signs of user frustration (repeated attempts to
complete the same thing?) and add to the frustration by silently
fixing the cache.
-- %< --
Subject: completion: do not cache merge strategy list
If "git merge -s help" fails the first time we try it (e.g. if you're
not in a git directory), git merge -s <TAB><TAB> never completes
correctly within the same session.
Reported-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 748d4f9..634941f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -332,7 +332,7 @@ __git_list_merge_strategies ()
__git_compute_merge_strategies ()
{
- : ${__git_merge_strategies=$(__git_list_merge_strategies)}
+ __git_merge_strategies=$(__git_list_merge_strategies)
}
__git_complete_file ()
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-14 10:35 UTC (permalink / raw)
To: Stephen Boyd
Cc: Kirill Smelkov, Sverre Rabbelier, Junio C Hamano, Shawn O. Pearce,
git
In-Reply-To: <4AFDC4F3.1050607@gmail.com>
Stephen Boyd wrote:
> I was under the impression that setting variables during completion
> meant they were lost at the end of the completion cycle. So to be
> safe I put a 'sleep 5' in __git_list_porcelain_commands() and it
> only stalled me once :-)
Clever. :)
> Plus it seems that __git_all_commands is computed twice if I git
> <TAB><TAB> and then git help <TAB><TAB> after. Can that be avoided?
Sounds like a bug; thanks. I’ll squash in something like the following
for the next iteration.
-- %< --
Subject: completion: avoid computing command list twice
__git_all_commands is being computed twice on git <TAB><TAB> with
git help <TAB><TAB> after.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
contrib/completion/git-completion.bash | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 6817953..748d4f9 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -588,6 +588,7 @@ __git_list_porcelain_commands ()
__git_compute_porcelain_commands ()
{
+ __git_compute_all_commands
: ${__git_porcelain_commands=$(__git_list_porcelain_commands)}
}
--
1.6.5.2
^ permalink raw reply related
* Re: GNU patch: new 2.6 release
From: Andreas Gruenbacher @ 2009-11-14 10:17 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git, bug-patch
In-Reply-To: <6672d0160911140045h70243c12w3c56ad925dc70d39@mail.gmail.com>
On Saturday 14 November 2009 09:45:11 am Björn Gustavsson wrote:
> Do you have any plans to support git-style binary patches?
Support for git's extended header lines for renames, copies, hashes, file
modes would be great. I'll happily take patches or eventually implement it
myself. Binary patches are not as high on my wish list, but feel free to send
code.
> That would be very useful in a workflow when you work in git (and have some
> binary files in the repository), but need to commit your finished work
> into another VCS (such as Clearcase).
Isn't there a better way to do this than with patches?
Thanks,
Andreas
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Nanako Shiraishi @ 2009-11-14 9:01 UTC (permalink / raw)
To: Raman Gupta; +Cc: git, trast, gitster
In-Reply-To: <4AFE41AF.8050802@fastmail.fm>
Quoting Raman Gupta <rocketraman@fastmail.fm>
> Ok, another dumb question: since you have now submitted a patch on top
> of my patch, what is the proper etiquette for proceeding? Who
> maintains this patch series until it is committed? Since your patch
> applies on top of mine I can't really make any more changes without
> affecting your patch right? I can't find any guidance in the
> SubmittingPatches document.
What usually happens is that we wait now.
In this case we are in agreement that it is a good idea to apply
both of our patches (mine was only repeating what Junio said in
his comments), so if I were you, I would anticipate that Junio
would apply both of them and start preparing incremental updates
on top of them now, and send them when the patches appear in his
'pu' branch.
Junio has gone quiet for the past few days; maybe he is too busy
to read or respond to either of our patch. Instead of preparing
the final text you write in the document in a patch format, it
may be a better to bring up your ideas here and discuss them
first. What changes do you have in mind? I think the new section
now already is in a reasonable shape.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Björn Gustavsson @ 2009-11-14 8:59 UTC (permalink / raw)
To: Raman Gupta; +Cc: Nanako Shiraishi, git, trast, gitster
In-Reply-To: <4AFE41AF.8050802@fastmail.fm>
On Sat, Nov 14, 2009 at 6:35 AM, Raman Gupta <rocketraman@fastmail.fm> wrote:
>
> Ok, another dumb question: since you have now submitted a patch on top
> of my patch, what is the proper etiquette for proceeding? Who
> maintains this patch series until it is committed? Since your patch
> applies on top of mine I can't really make any more changes without
> affecting your patch right? I can't find any guidance in the
> SubmittingPatches document.
I can't answer the questions about proper etiquette, but you *can* do
more changes
if you first apply Nanako's patch on top of your previous changes.
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: GNU patch: new 2.6 release
From: Björn Gustavsson @ 2009-11-14 8:45 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <200911140109.34202.agruen@suse.de>
On Sat, Nov 14, 2009 at 1:09 AM, Andreas Gruenbacher <agruen@suse.de> wrote:
> I am pleased to announce my first release of GNU patch,
Nice to see a new release.
Do you have any plans to support git-style binary patches?
That would be very useful in a workflow when you work in git (and have some
binary files in the repository), but need to commit your finished work
into another VCS (such as Clearcase).
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* [PATCH] rebase -i: Simplify handling of invalid commands.
From: Greg Price @ 2009-11-14 8:11 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano, Jan Krüger
A few weeks ago there was a bug report that some invalid commands
produced confusing error messages. The fix could have made things
simpler. There's no need for die_with_patch in this case, because its
purpose is to tell rerere and a future rebase --continue about a
commit that we just attempted, and we didn't attempt any commit. So
just use a plain "die" unconditionally.
Signed-off-by: Greg Price <price@mit.edu>
---
git-rebase--interactive.sh | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 53ad248..6d0ca7b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -416,12 +416,7 @@ do_next () {
;;
*)
warn "Unknown command: $command $sha1 $rest"
- if git rev-parse --verify -q "$sha1" >/dev/null
- then
- die_with_patch $sha1 "Please fix this in the file $TODO."
- else
- die "Please fix this in the file $TODO."
- fi
+ die "Please fix this in the file $TODO."
;;
esac
test -s "$TODO" && return
--
1.6.5.2.27.g906c6.dirty
^ permalink raw reply related
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Raman Gupta @ 2009-11-14 5:35 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, trast, gitster
In-Reply-To: <20091114081040.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting Raman Gupta <rocketraman@fastmail.fm>
>> I noticed you removed the discussion I added about the situation in
>> which maint will *not* be a subset of master i.e. when the user has
>> cherry-picked commits from other branches. This type of cherry-pick is
>> described as a valid operation, though one to generally be avoided
>> earlier in the man page. If we tell users that the occasional
>> cherry-pick to maint is ok, then shouldn't we explain how that affects
>> the release process?
>
> It is irrelevant that you can cherry-pick to 'maint'.
>
> You can, and Junio does, cherry-pick some commits from master to
> maint from time to time. But even if you have such cherry-picked
> commits on the maintenance branch, the result, with zero or more
> other maintenance commits on top, is always merged back to the
> master branch (you can look at "gitk origin/maint origin/master"
> to see yourself).
>
> So when Junio tags the release from the tip of the master branch,
> it is a superset of the maintenace branch; it is irrelevant if
> maint has some commits that are cherry-picked from master.
Thanks for the explanation. Makes sense.
Ok, another dumb question: since you have now submitted a patch on top
of my patch, what is the proper etiquette for proceeding? Who
maintains this patch series until it is committed? Since your patch
applies on top of mine I can't really make any more changes without
affecting your patch right? I can't find any guidance in the
SubmittingPatches document.
Cheers,
Raman
^ permalink raw reply
* [PATCH 2/2] ls-tree: migrate to parse-options
From: Stephen Boyd @ 2009-11-14 4:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1258173248-31059-1-git-send-email-bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
builtin-ls-tree.c | 100 +++++++++++++++++++++-------------------------------
1 files changed, 40 insertions(+), 60 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index 22008df..04408df 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -9,6 +9,7 @@
#include "commit.h"
#include "quote.h"
#include "builtin.h"
+#include "parse-options.h"
static int line_termination = '\n';
#define LS_RECURSIVE 1
@@ -22,8 +23,10 @@ static const char **pathspec;
static int chomp_prefix;
static const char *ls_tree_prefix;
-static const char ls_tree_usage[] =
- "git ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] <tree-ish> [path...]";
+static const char * const ls_tree_usage[] = {
+ "git ls-tree [-d] [-r] [-t] [-l | --long] [-z] [--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=<n>]] <tree-ish> [path...]",
+ NULL
+};
static int show_recursive(const char *base, int baselen, const char *pathname)
{
@@ -117,76 +120,53 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
{
unsigned char sha1[20];
struct tree *tree;
+ int full_tree = 0;
+ const struct option ls_tree_options[] = {
+ OPT_BIT('d', NULL, &ls_options, "only show trees",
+ LS_TREE_ONLY),
+ OPT_BIT('r', NULL, &ls_options, "recurse into subtrees",
+ LS_RECURSIVE),
+ OPT_BIT('t', NULL, &ls_options, "show trees when recursing",
+ LS_SHOW_TREES),
+ OPT_SET_INT('z', NULL, &line_termination,
+ "terminate entries with NUL byte", 0),
+ OPT_BIT('l', "long", &ls_options, "include object size",
+ LS_SHOW_SIZE),
+ OPT_BIT(0, "name-only", &ls_options, "list only filenames",
+ LS_NAME_ONLY),
+ OPT_BIT(0, "name-status", &ls_options, "list only filenames",
+ LS_NAME_ONLY),
+ OPT_SET_INT(0, "full-name", &chomp_prefix,
+ "use full path names", 0),
+ OPT_BOOLEAN(0, "full-tree", &full_tree,
+ "list entire tree; not just current directory "
+ "(implies --full-name)"),
+ OPT__ABBREV(&abbrev),
+ OPT_END()
+ };
git_config(git_default_config, NULL);
ls_tree_prefix = prefix;
if (prefix && *prefix)
chomp_prefix = strlen(prefix);
- while (1 < argc && argv[1][0] == '-') {
- switch (argv[1][1]) {
- case 'z':
- line_termination = 0;
- break;
- case 'r':
- ls_options |= LS_RECURSIVE;
- break;
- case 'd':
- ls_options |= LS_TREE_ONLY;
- break;
- case 't':
- ls_options |= LS_SHOW_TREES;
- break;
- case 'l':
- ls_options |= LS_SHOW_SIZE;
- break;
- case '-':
- if (!strcmp(argv[1]+2, "name-only") ||
- !strcmp(argv[1]+2, "name-status")) {
- ls_options |= LS_NAME_ONLY;
- break;
- }
- if (!strcmp(argv[1]+2, "long")) {
- ls_options |= LS_SHOW_SIZE;
- break;
- }
- if (!strcmp(argv[1]+2, "full-name")) {
- chomp_prefix = 0;
- break;
- }
- if (!strcmp(argv[1]+2, "full-tree")) {
- ls_tree_prefix = prefix = NULL;
- chomp_prefix = 0;
- break;
- }
- if (!prefixcmp(argv[1]+2, "abbrev=")) {
- abbrev = strtoul(argv[1]+9, NULL, 10);
- if (abbrev && abbrev < MINIMUM_ABBREV)
- abbrev = MINIMUM_ABBREV;
- else if (abbrev > 40)
- abbrev = 40;
- break;
- }
- if (!strcmp(argv[1]+2, "abbrev")) {
- abbrev = DEFAULT_ABBREV;
- break;
- }
- /* otherwise fallthru */
- default:
- usage(ls_tree_usage);
- }
- argc--; argv++;
+
+ argc = parse_options(argc, argv, prefix, ls_tree_options,
+ ls_tree_usage, 0);
+ if (full_tree) {
+ ls_tree_prefix = prefix = NULL;
+ chomp_prefix = 0;
}
/* -d -r should imply -t, but -d by itself should not have to. */
if ( (LS_TREE_ONLY|LS_RECURSIVE) ==
((LS_TREE_ONLY|LS_RECURSIVE) & ls_options))
ls_options |= LS_SHOW_TREES;
- if (argc < 2)
- usage(ls_tree_usage);
- if (get_sha1(argv[1], sha1))
- die("Not a valid object name %s", argv[1]);
+ if (argc < 1)
+ usage_with_options(ls_tree_usage, ls_tree_options);
+ if (get_sha1(argv[0], sha1))
+ die("Not a valid object name %s", argv[0]);
- pathspec = get_pathspec(prefix, argv + 2);
+ pathspec = get_pathspec(prefix, argv + 1);
tree = parse_tree_indirect(sha1);
if (!tree)
die("not a tree object");
--
1.6.5.2.155.gbb47
^ permalink raw reply related
* [PATCH 1/2] t3101: test more ls-tree options
From: Stephen Boyd @ 2009-11-14 4:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1258173248-31059-1-git-send-email-bebarino@gmail.com>
Add tests for --full-name, --full-tree, --abbrev, and --name-only.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
t/t3101-ls-tree-dirname.sh | 89 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/t/t3101-ls-tree-dirname.sh b/t/t3101-ls-tree-dirname.sh
index 51cb4a3..99458e4 100755
--- a/t/t3101-ls-tree-dirname.sh
+++ b/t/t3101-ls-tree-dirname.sh
@@ -39,8 +39,8 @@ test_expect_success \
tree=`git write-tree` &&
echo $tree'
-_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
-_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+_x5='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
+_x40="$_x5$_x5$_x5$_x5$_x5$_x5$_x5$_x5"
test_output () {
sed -e "s/ $_x40 / X /" <current >check
test_cmp expected check
@@ -141,4 +141,89 @@ test_expect_success 'ls-tree filter is leading path match' '
test_output
'
+test_expect_success 'ls-tree --full-name' '
+ (
+ cd path0 &&
+ git ls-tree --full-name $tree a
+ ) > current &&
+ cat >expected <<\EOF &&
+040000 tree X path0/a
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --full-tree' '
+ (
+ cd path1/b/c &&
+ git ls-tree --full-tree $tree
+ ) > current &&
+ cat >expected <<\EOF &&
+100644 blob X 1.txt
+100644 blob X 2.txt
+040000 tree X path0
+040000 tree X path1
+040000 tree X path2
+040000 tree X path3
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --full-tree -r' '
+ (
+ cd path3/ &&
+ git ls-tree --full-tree -r $tree
+ ) > current &&
+ cat >expected <<\EOF &&
+100644 blob X 1.txt
+100644 blob X 2.txt
+100644 blob X path0/a/b/c/1.txt
+100644 blob X path1/b/c/1.txt
+100644 blob X path2/1.txt
+100644 blob X path3/1.txt
+100644 blob X path3/2.txt
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --abbrev=5' '
+ git ls-tree --abbrev=5 $tree > current.abbrev &&
+ sed -e "s/ $_x5 / X /" < current.abbrev > current &&
+ cat >expected <<\EOF &&
+100644 blob X 1.txt
+100644 blob X 2.txt
+040000 tree X path0
+040000 tree X path1
+040000 tree X path2
+040000 tree X path3
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --name-only' '
+ git ls-tree --name-only $tree > current
+ cat >expected <<\EOF &&
+1.txt
+2.txt
+path0
+path1
+path2
+path3
+EOF
+ test_output
+'
+
+test_expect_success 'ls-tree --name-only -r' '
+ git ls-tree --name-only -r $tree > current
+ cat >expected <<\EOF &&
+1.txt
+2.txt
+path0/a/b/c/1.txt
+path1/b/c/1.txt
+path2/1.txt
+path3/1.txt
+path3/2.txt
+EOF
+ test_output
+'
+
test_done
--
1.6.5.2.155.gbb47
^ permalink raw reply related
* [PATCH 0/2] Migrate ls-tree to parse-opts
From: Stephen Boyd @ 2009-11-14 4:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This looked pretty straightforward. I guess --name-status is there
for backward compatibility. Should it be there anymore?
Stephen Boyd (2):
t3101: test more ls-tree options
ls-tree: migrate to parse-options
builtin-ls-tree.c | 100 +++++++++++++++++--------------------------
t/t3101-ls-tree-dirname.sh | 89 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 127 insertions(+), 62 deletions(-)
^ permalink raw reply
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Nanako Shiraishi @ 2009-11-14 2:12 UTC (permalink / raw)
To: Peter Krefting
Cc: Junio C Hamano, Thomas Rast, Nicolas Sebrecht, Baz,
Git Mailing List, Johannes.Schindelin, B.Steinbrink
In-Reply-To: <alpine.DEB.2.00.0911121034580.8825@ds9.cixit.se>
Quoting Peter Krefting <peter@softwolves.pp.se>
> The web tree checkout script uses rebase to avoid introducing merge
> commits every time the blog comment is updated, as it in 99 % of cases
> is unrelated to any other changes found in the central repo.
>
> In the few cases where the blog comment update from the web tree
> conflicts with a change in the central repo, I want the "git pull
> --rebase" call to overwrite any changes in the central repo with my
> changes in the web tree (meaning that I would later have to manually
> re-delete the spam comments, but I can live with that).
That sounds like "-Xours" merge option that was discussed some time
ago. See
http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021
I remember that Junio and Petr were against it because it would
encourage a bad workflow. Dscho was against the syntax used to
pass the options also.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH] git-add.txt: fix formatting of --patch section
From: Stephen Boyd @ 2009-11-14 1:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Extra paragraphs should be prefixed with a plus sign.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Documentation/git-add.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45ebf87..e93e606 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -76,10 +76,10 @@ OPTIONS
work tree and add them to the index. This gives the user a chance
to review the difference before adding modified contents to the
index.
-
- This effectively runs ``add --interactive``, but bypasses the
- initial command menu and directly jumps to `patch` subcommand.
- See ``Interactive mode'' for details.
++
+This effectively runs `add --interactive`, but bypasses the
+initial command menu and directly jumps to the `patch` subcommand.
+See ``Interactive mode'' for details.
-e, \--edit::
Open the diff vs. the index in an editor and let the user
--
1.6.5.2.155.gbb47
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox