* Re: [PATCH] Trim hint printed when gecos is empty.
From: Han-Wen Nienhuys @ 2006-11-28 10:52 UTC (permalink / raw)
To: git
In-Reply-To: <ekh2uh$nk2$1@sea.gmane.org>
Han-Wen Nienhuys escreveu:
> Trim hint printed when gecos is empty.
> Remove asterisks for readability
> Suggest use of git-config for easy cut & pasting.
> ---
and
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
is there a reason why git-format-patch doesn't add a sign-off by default?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: can I remove or move a tag in a remote repository?
From: Andreas Ericsson @ 2006-11-28 11:08 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87wt5rffbm.fsf@rho.meyering.net>
Jim Meyering wrote:
>
> Perhaps I shouldn't push the cvs-head tag at all.
Possibly not, although it's nice to let others that use git to know
where you've cut the release.
> A few questions:
> - is there a way to say "push all tags matching /COREUTILS-*/"
> or to say "push all tags, except the ones on this list"?
Here's a snippet from the default update hook we use on all our repos.
We explicitly deny any non-annotated tags from being pushed to the
central server and let rogue devs know why the push failed by writing
the error message to stderr so that it gets sent over the wire. I
believe this is still the default update-hook shipped with git.
---%<---%<----%<---
ref_type=$(git cat-file -t "$3")
# Only allow annotated tags in a shared repo
# Remove this code to treat dumb tags the same as everything else
case "$1","$ref_type" in
refs/tags/*,commit)
echo "*** Un-annotated tags are not allowed in this repo" >&2
echo "*** Use 'git tag [ -a | -s ]' for tags you want to
propagate." >&2
exit 1;;
---%<---%<---%<---
> - is there a way to remove the cvs-head tag from the remote directory?
> Note: I don't have shell access there. I can request that someone
> with shell access do it, but shouldn't have to resort to that.
> - is there some way to make "git push" do what I want, and update the
> offending tag in the remote repo?
>
I'm not sure if execution reaches the update hook when you're uploading
a tag that already exists. If it is, you could simply remove the
offending tag in the update-hook and exit 0 to make it work properly.
You can test this without shell-access on the remote system by setting
up a repo on your local machine, making some dummy commit, cloning it
and then hacking away on the hook while pushing to it from your local repo.
Other than that, push your tags manually by naming them explicitly on
the push-line, like so:
$ git push $remote_repo $tag_name
This is what I do whenever we cut a release. With a one tag per release,
it's not very troublesome at all, and the update-hook sends a nicely
formatted message of the changes since the last release (last tag
really, but it amounts to the same thing for us) to everyone involved.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] Trim hint printed when gecos is empty.
From: Jakub Narebski @ 2006-11-28 11:15 UTC (permalink / raw)
To: git
In-Reply-To: <ekh4cu$q6e$2@sea.gmane.org>
Han-Wen Nienhuys wrote:
> Han-Wen Nienhuys escreveu:
>> Trim hint printed when gecos is empty.
>> Remove asterisks for readability
>> Suggest use of git-config for easy cut & pasting.
>> ---
>
> and
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
>
> is there a reason why git-format-patch doesn't add a sign-off by default?
Yes. You are supposed to add Signed-off-by on commit (I hope that
git-format-patch doesn't dulicate signoff lines), using git-commit -s.
But perhaps a config option...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Trim hint printed when gecos is empty.
From: Andy Parkins @ 2006-11-28 11:46 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <ekh5k8$vih$1@sea.gmane.org>
On Tuesday 2006 November 28 11:15, Jakub Narebski wrote:
> Yes. You are supposed to add Signed-off-by on commit (I hope that
> git-format-patch doesn't dulicate signoff lines), using git-commit -s.
> But perhaps a config option...
I achieve reasonable results by having the following in my .git/config
[format]
headers = "To: git@vger.kernel.org\n"
[alias]
email=format-patch --signoff --stdout
By tuning this per-project I know that a "git email" will generate the correct
sort of patch for this project.
The thing that's missing is a config option to make git-commit add the signoff
automatically. I think this would be useful, as "signing off" is probably a
per-project decision rather than a per-commit decision. It seems awkward to
require the user to remember what the project policy is and always get the
right git-commit for each project.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* [PATCH] Add support for commit.signoff config option
From: Andy Parkins @ 2006-11-28 12:02 UTC (permalink / raw)
To: git
Whether patches require signing off or not is probably a per-project
setting rather than a per-commit setting. Therefore as a convenience to
the user, the commit.signoff setting will automtically add --signoff to
commits.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
git-commit.sh | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..c45af10 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -66,9 +66,7 @@ trap '
rm -f "$NEXT_INDEX"
' 0
-################################################################
-# Command line argument parsing and sanity checking
-
+# Init
all=
also=
only=
@@ -85,6 +83,17 @@ signoff=
force_author=
only_include_assumed=
untracked_files=
+
+# Config
+case "$(git-repo-config --get commit.signoff)" in
+1|on|yes|true)
+ signoff=t
+ ;;
+esac
+
+################################################################
+# Command line argument parsing and sanity checking
+
while case "$#" in 0) break;; esac
do
case "$1" in
--
1.4.3.GIT-dirty
^ permalink raw reply related
* Re: git and bzr
From: Erik Bågfors @ 2006-11-28 12:10 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: git, bazaar-ng
In-Reply-To: <456B7C6A.80104@webdrake.net>
> Next question ... one of the reasons I started seriously thinking about
> git was that in the VCS comparison discussion, it was noted that git is
> a lot more flexible than bzr in terms of how it can track data (e.g. the
> git pickaxe command, although I understand that's not in the released
> version [1.4.4.1] yet?).
If this is blame/annotate, this exists in bzr as well...
: [bagfors@zyrgelkwyt]$ ; bzr help blame
usage: bzr annotate FILENAME
aliases: ann, blame, praise
Show the origin of each line in a file.
^ permalink raw reply
* Re: Possible BUG with git-rev-list --all in a StGit repository
From: Marco Costalba @ 2006-11-28 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: catalin.marinas, Git Mailing List
In-Reply-To: <7vd57855fy.fsf@assigned-by-dhcp.cox.net>
On 11/28/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> >> If you (as a Porcelain) want to get all refs under refs/heads/,
> >> there are (unfortunately) two ways to get that list. I would
> >> suggest obtain the refs you want that way, pass them as command
> >> line arguments to rev-list.
> >
> > Unfortunatly that does not work in case a branch and a tag have the same name.
>
> I am not quite grokking what the problem you are trying to solve
> is, so this is a shot in the dark, but
>
> git rev-list refs/heads/test refs/tags/test
>
> to disambiguate, perhaps?
>
Interesting!
I didn't think about 'full path' explicitation. If the barnches are
always and only under refs/heads this should work.
Thanks
^ permalink raw reply
* Re: Mozilla, git and Windows
From: Michael Haggerty @ 2006-11-28 12:17 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, Andy Whitcroft, Git Mailing List, dev
In-Reply-To: <9e4733910611271735y14bed29bk70ae67b5d28eb055@mail.gmail.com>
Jon Smirl wrote:
> As was mentioned in the thread about doing CVS to git import, the
> trick is to write your own CVS file parser, parse the file once (not
> once for each revision) and output all of the revisions to the git
> database in a single pass. When code is structured that way I can
> import the whole Mozilla repository into git in two hours. The
> fast-import back end also works with out forking, it just listens to
> command and stdin and acts on them, all of the commands are implement
> in a single binary.
Using cvs2svn, it is now possible to avoid having to invoke CVS/RCS
zillions of times. Here is a brief description of how the new hooks work.
There is an interface called RevisionReader that is used to retrieve the
contents of a file. The RevisionReader that should be used for a run of
cvs2svn can be set using the --options file method with a line like:
ctx.revision_reader = MyRevisionReader()
The RevisionReader interface includes a method get_revision_recorder(),
which should return an instance of RevisionRecorder. The
RevisionRecorder has callback methods that are invoked as the CVS files
are parsed. For example, RevisionRecorder.record_text() is passed the
log message and text (full text or delta) for each file revision. The
record_text() method is allowed to return an arbitrary token (for
example, a content hash), and that token is stored into
CVSRevision.revision_recorder_token and carried along by cvs2svn.
The concrete RevisionReaders included with cvs2svn are RCSRevisionReader
and CVSRevisionReader, which have do-nothing RevisionRecorders and which
call rcs or cvs in OutputPass to get the file contents. (This repeated
invocation of rcs/cvs is the most expensive part of the conversion.)
So what you would do to speed things up is write your own
RevisionRecorder, which constructs the file fulltext from the CVS deltas
and stores the contents in a git store, returning the file revision's
content hash as token.
Then write a RevisionReader that returns an instance of your
RevisionRecorder to be used in the CollectRevsPass of the conversion.
For OutputPass, the RevisionReader has to implement the method
get_content_stream(), which is passed a CVSRevision instance and has to
return a stream object that produces the file revision's contents. In
your case, you wouldn't need the contents at all, but could just work
with CVSRevision.revision_recorder_token, which contains the hash that
was generated by your RevisionRecorder.
How you actually cook these tokens together into a git repository is up
to you :-)
Michael
^ permalink raw reply
* Re: git and bzr
From: Jakub Narebski @ 2006-11-28 12:37 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <845b6e870611280410j58bdcd99nc05d0f67489293e4@mail.gmail.com>
Erik B?gfors wrote:
>> Next question ... one of the reasons I started seriously thinking about
>> git was that in the VCS comparison discussion, it was noted that git is
>> a lot more flexible than bzr in terms of how it can track data (e.g. the
>> git pickaxe command, although I understand that's not in the released
>> version [1.4.4.1] yet?).
>
> If this is blame/annotate, this exists in bzr as well...
>
> : [bagfors@zyrgelkwyt]$ ; bzr help blame
> usage: bzr annotate FILENAME
> aliases: ann, blame, praise
>
> Show the origin of each line in a file.
That doesn't change the fact that "git pickaxe" abilities in "git blame"
is more than just equivalent of "cvs annotate".
----
bzr annotate FILENAME
Show the origin of each line in a file.
----
git-blame [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>]
[-M] [-C] [-C] [--since=<date>] [<rev>] [--] <file>
Annotates each line in the given file with information from the revision
which last modified the line. Optionally, start annotating from the given
revision.
Also it can limit the range of lines annotated.
[...]
Also you can use regular expression to specify the line range.
git blame -L '/^sub hello {/,/^}$/' foo
would limit the annotation to the body of hello subroutine.
When you are not interested in changes older than the version v2.6.18, or
changes older than 3 weeks, you can use revision range specifiers similar
to git-rev-list:
git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo
http://kernel.org/pub/software/scm/git/docs/git-blame.html
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1.2/2 (fixed)] git-svn: fix output reporting from the delta fetcher
From: Pazu @ 2006-11-28 12:45 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061128105017.GA20366@soma>
I've tried applying the patch, and running init'ing a new git-svn
repository for my project. The initial commit was fetched OK (and very
fast!), but now I get the following error trying to fetch any later
revision:
Error from SVN, (200003): Incomplete data: Delta source ended unexpectedly
at /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/SVN/Ra.pm line 157
512 at /Users/pazu/bin/git-svn line 448
main::fetch_lib() called at /Users/pazu/bin/git-svn line 319
main::fetch() called at /Users/pazu/bin/git-svn line 178
I'm on Mac OS X 10.4.8 (Intel), with perl 5.8.8 compiled from
macports, and SVN perl bindings from subversion 1.4.0, also compiled
from macports. git was built from 'master' plus your patches.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Josef Weidendorfer @ 2006-11-28 13:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7vd5786opj.fsf@assigned-by-dhcp.cox.net>
On Tuesday 28 November 2006 07:59, Junio C Hamano wrote:
> Once I am done, I can ask "git diff" and expect it to show my
> local changes I have no intention of committing for now
> ...
>
> And at that point, I trust "git commit" to do the right thing --
> the damn thing I just checked with "git diff --cached" _is_ what
> will be committed.
I think the difference behavior between "git commit" and "git diff" is
a little bit confusing.
Currently, we have
* "git diff" shows what "git commit -a" would commit
* "git diff --cached" shows what "git commit" would commit
IMHO, "git diff" should show what's in the staging area,
and we should introduce "git diff -a" as a way to see the full
changes.
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Jeff King @ 2006-11-28 13:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Linus Torvalds
In-Reply-To: <7v7ixge8j2.fsf@assigned-by-dhcp.cox.net>
On Mon, Nov 27, 2006 at 04:09:53PM -0800, Junio C Hamano wrote:
> Interesting. While driving to work this morning I had the same
> thought. A revision that does not appear in the output from
>
> for file in $(list of files the commit touches)
> do
> git blame v2.6.17..v2.6.18 -- $file
> done
Just for fun, I took a look at what we might see by ordering commits by
their "amount of blamedness". That is, the count of lines introduced by
a commit which were not later superseded. The script I used is below:
#!/bin/sh
start=$1; shift
end=$1; shift
start_sha1=`git-rev-parse $start^{}`
git-rev-list --parents $start..$end >revs
echo $start_sha1 >>revs
for i in `git-diff --raw -r $start $end | cut -f2`; do
echo blaming $i... >&2
git-blame -l -S revs $i | cut -d' ' -f1
done |
grep -v $start_sha1 |
sort | uniq -c | sort -rn |
while read count hash; do
echo "$count `git-rev-list --max-count=1 --pretty=oneline $hash`"
done
The top 15 for v1.4.3 to v1.4.4 are:
1604 6973dcaee76ef7b7bfcabd2f26e76205aae07858 Libify diff-files.
1100 9f613ddd21cbd05bfc139d9b1551b5780aa171f6 Add git-for-each-ref: helper for language bindings
1050 cee7f245dcaef6dade28464f59420095a9949aac git-pickaxe: blame rewritten.
700 58e60dd203362ecb9fdea765dcc2eb573892dbaf Add support for pushing to a remote repository using HTTP/DAV
571 9f1afe05c3ab7228e21ba3666c6e35d693149b37 gitk: New improved gitk
524 197e8951abd2ebf2c70d0847bb0b38b16b92175b http-push: support for updating remote info/refs
504 83b5d2f5b0c95fe102bc3d1cc2947abbdf5e5c5b builtin-grep: make pieces of it available as library.
462 aa1dbc9897822c8acb284b35c40da60f3debca91 Update http-push functionality
344 a57a9493df00b6fbb3699fda8ceedf4ac0783ac6 Added Perl git-cvsimport-script
343 f8b28a4078a29cbf93cac6f9edd8d5c203777313 gitk: Add a tree-browsing mode
323 00449f992b629f7f7884fb2cf46ff411a2a4f381 Make git-fmt-merge-msg a builtin
285 fd8ccbec4f0161b14f804a454e68b29e24840ad3 gitk: Work around Tcl's non-standard names for encodings
283 9cf6d3357aaaaa89dd86cc156221b7b604e9358c Add git-index-pack utility
277 e4fbbfe9eccd37c0f9c060eac181ce05988db76c Add git-zip-tree
256 da7c24dd9c75d014780179f8eb843968919e4c46 gitk: Basic support for highlighting one view within another
The bottom 15 are:
1 076b2324cdca9a2825c569cf9ec02d219c237e26 show-branch: make it work in a subdirectory.
1 061303f0b50a648db8e0af23791fc56181f6bf93 cvsimport: always set $ENV{GIT_INDEX_FILE} to $index{$branch}
1 057bc808b4aa2e7795f9bd395e68071301bc0b74 path-list: fix path-list-insert return value
1 04c13d38772c77997d8789ee2067cc351b66e2aa Save the maxwidth setting in the ~/.gitk file.
1 041a7308de3e6af36c5a6cc3412b542f42314f3f sha1_name.c: prepare to make get_tree_entry() reusable from others.
1 0360e99d06acfbb0fcb72215cf6749591ee53290 [PATCH] Fix git-rev-parse --default and --flags handling
1 02d3dca3bff6a67dead9f5b97dfe3576fe5b14e5 revision.c: fix "dense" under --remove-empty
1 02c5cba2007856465710aa37cd41b404372ab95b find_unique_abbrev() with len=0 should not abbreviate
1 02853588a48eddbaa42b58764960394e416d68bf Typofix in Makefile comment.
1 024701f1d88d79f3777bf45c82437f40a80b6eaa Make pack-objects chattier.
1 021b6e454944a4fba878651ebf9bfe0a3f6c3077 Make index file locking code reusable to others.
1 01ff767a3266a1876ce24a200c45786083768fda Merge branch 'lt/refs' into next
1 01385e275828c1116ea9bfcf827f82f450ee8f5f Comment fixes.
1 013049c985e4095106e545559c17bc594d56468d revert/cherry-pick: handle single quote in author name.
1 0086e2c854e3af3209915e4ec2f933bcef400050 Rename lost+found to lost-found.
This approach isn't without value; the top lines really _are_ important
changes, as they show where a lot of work (line-wise) went. The bottom
lines are relatively unimportant (oh boy, comment fixes!). But there
are obviously some one-liners that are very interesting. For example:
1 0abc0260fa3419de649fcc1444e3d256a17ca6c7 pager: default to LESS=FRSX not LESS=FRS
generated quite a bit of discussion on the list, and end users would
care about it.
I think it's clear that "important commits" is going to be something we
determine through heuristics; blame-able lines is probably a heuristic
worth considering.
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Jakub Narebski @ 2006-11-28 13:23 UTC (permalink / raw)
To: git
In-Reply-To: <200611281400.37191.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> On Tuesday 28 November 2006 07:59, Junio C Hamano wrote:
>> Once I am done, I can ask "git diff" and expect it to show my
>> local changes I have no intention of committing for now
>> ...
>>
>> And at that point, I trust "git commit" to do the right thing --
>> the damn thing I just checked with "git diff --cached" _is_ what
>> will be committed.
>
> I think the difference behavior between "git commit" and "git diff" is
> a little bit confusing.
>
> Currently, we have
> * "git diff" shows what "git commit -a" would commit
> * "git diff --cached" shows what "git commit" would commit
>
> IMHO, "git diff" should show what's in the staging area,
> and we should introduce "git diff -a" as a way to see the full
> changes.
I see it in other way. "git diff" tells us if a tree has changed wrt. what
would be committed. It is not a preview of commit.
Also, as of now the version without additional option is a fastest one, both
for diff and for commit.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Trim hint printed when gecos is empty.
From: Johannes Schindelin @ 2006-11-28 13:28 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Jakub Narebski
In-Reply-To: <200611281146.56201.andyparkins@gmail.com>
Hi,
On Tue, 28 Nov 2006, Andy Parkins wrote:
> The thing that's missing is a config option to make git-commit add the
> signoff automatically.
No. As has been often said, a signoff _has_ to be a conscious act, or else
it will lose its meaning.
Once you are reasonably convinced you want to sign off on that commit,
just add "-s" to git-commit. And if you forgot, fix it by "git commit -s
--amend". (Note that this is another nice example why "-a" by default
would be wrong, wrong, wrong.)
Ciao,
Dscho
^ permalink raw reply
* Re: git and bzr
From: Johannes Schindelin @ 2006-11-28 13:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, bazaar-ng
In-Reply-To: <ekhaeg$etk$1@sea.gmane.org>
Hi,
On Tue, 28 Nov 2006, Jakub Narebski wrote:
> [... some reasons why git-annotate is not just your regular annotate ...]
You should also mention that git-annotate can follow code movements
through file renames.
I know, because I was already rightfully blamed for code which was moved
by somebody else.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-11-28 13:35 UTC (permalink / raw)
To: git
In-Reply-To: <ekh45n$rfc$1@sea.gmane.org>
On Tuesday 2006 November 28 10:50, Jakub Narebski wrote:
> I think that the proper place for that would be supermodule _index_.
> The supermodule tree would have commit entry, and the index would have
> symbolic branch (and perhaps some infor about where to find refs for
> submodule).
>
> This I guess breaks index abstraction slightly, but on the other hand
> allows for tracking non-HEAD branch of submodule, and for submodule to
> not know about supermodule at all...
The reason I thought it would have to be HEAD at all times, is to prevent
situations where the supermodule commit doesn't reflect the state of the
current tree.
Let's imagine that we're doing non-HEAD tracking in the supermodule.
supermodule
+-------- libsubmodule1
+-------- libsubmodule2
So, you do a "make" in supermodule; this of course will call make in each of
the submodules. You test the output and find that it's all working nicely.
Time for a supermodule commit. We want to freeze this working state. You
commit and tag "supermodule-rc1"
Unfortunately, during development, you've switched libsubmodule1 to
branch "development", but supermodule isn't tracking libsubmodule1/HEAD it's
tracking libsubmodule1/master. Your supermodule commit doesn't capture a
snapshot of the tree you're using.
Now you say to the mailing list "hey guys, can you test "supermodule-rc1"?
They check it out, and find that everything is broken. Why? Because what
you wanted to check in was libsubmodule@development, but what actually went
in was libsubmodule@master.
I think I've talked myself into the position where it definitely has to be
HEAD being tracked in the submodules; anything else is a disaster waiting to
happen because commit doesn't check in your current tree.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Johannes Schindelin @ 2006-11-28 13:43 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <20061128131139.GA10874@coredump.intra.peff.net>
Hi,
On Tue, 28 Nov 2006, Jeff King wrote:
> I think it's clear that "important commits" is going to be something we
> determine through heuristics; blame-able lines is probably a heuristic
> worth considering.
I was surprised that not more of my stuff was in the top-15, since I
submitted less-than-finished patches quite often. Especially
merge-recursive was quite a bit of work for Alex and me.
BTW merge-recursive is a perfect example why this approach will break
down: most of the rewrite in C took place in a private repository with
quite some commits. This does not show in the git repository.
I fully expect the linux repository to behave similarly, since most of the
features are cooked elsewhere, and not all of them are pulled, but some
are applied (i.e. they appear out of nowhere from the repository's
viewpoint).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Jeff King @ 2006-11-28 13:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0611281439500.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Nov 28, 2006 at 02:43:49PM +0100, Johannes Schindelin wrote:
> BTW merge-recursive is a perfect example why this approach will break
> down: most of the rewrite in C took place in a private repository with
> quite some commits. This does not show in the git repository.
>
> I fully expect the linux repository to behave similarly, since most of the
> features are cooked elsewhere, and not all of them are pulled, but some
> are applied (i.e. they appear out of nowhere from the repository's
> viewpoint).
Yes, I think this would be more useful in concert with some sort of
grouping. If we can make a group of commits related to merge-recursive,
and score them as a single item, then they can be compared to other
groups (which may consist of a single commit or several).
^ permalink raw reply
* Re: [PATCH] Trim hint printed when gecos is empty.
From: Andy Parkins @ 2006-11-28 14:03 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0611281426311.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Tuesday 2006 November 28 13:28, Johannes Schindelin wrote:
> No. As has been often said, a signoff _has_ to be a conscious act, or else
> it will lose its meaning.
I'm not suggesting that a project integrator would have that switch on, but
for me, in my own repository, where I am the only person writing patches,
what possible case is there that I won't sign off?
> Once you are reasonably convinced you want to sign off on that commit,
I am always convinced. Perhaps I am doing wrong - please explain to me under
what circumstance I would /not/ want to sign off on a commit. (assuming I am
acting merely as a developer on a project, I am not accepting patches from
anyone but me).
> just add "-s" to git-commit. And if you forgot, fix it by "git commit -s
> --amend". (Note that this is another nice example why "-a" by default
> would be wrong, wrong, wrong.)
I don't see what one has to do with the other. There are good arguments for
not having "-a" default, but signing off isn't one of them.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] Trim hint printed when gecos is empty.
From: Johannes Schindelin @ 2006-11-28 14:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611281403.36370.andyparkins@gmail.com>
Hi,
On Tue, 28 Nov 2006, Andy Parkins wrote:
> On Tuesday 2006 November 28 13:28, Johannes Schindelin wrote:
>
> > No. As has been often said, a signoff _has_ to be a conscious act, or else
> > it will lose its meaning.
>
> I'm not suggesting that a project integrator would have that switch on,
> but for me, in my own repository, where I am the only person writing
> patches, what possible case is there that I won't sign off?
You are probably different than me. What with my track record, I _trust_
my patches to be not perfect at all. Nevertheless, I commit here and now,
and usually I regroup the commits into a nice patch (series) (AKA poor
man's StGit).
So I will never need something like you suggest. Having said that, if you
think it is best for you to mark every commit as signed-off-by you, just
add an alias:
git repo-config --global alias.c "commit -s"
and you're done. I highly doubt that it makes sense for the average
developer, though.
^ permalink raw reply
* [RFC] git-branch: add options and tests for branch renaming
From: Lars Hjemli @ 2006-11-28 14:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Extend git-branch with the following options:
git-branch -m|-M [<oldbranch>] newbranch
The -M variation is required to force renaming over an exsisting
branchname.
This also indroduces $GIT_DIR/RENAME_REF which is a "metabranch"
used when renaming branches. It will always hold the original sha1
for the latest renamed branch.
Additionally, if $GIT_DIR/logs/RENAME_REF exists, all branch rename
events are logged there.
Finally, some testcases are added to verify the new options.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/git-branch.txt | 23 +++++-
builtin-branch.c | 49 ++++++++++++-
refs.c | 169 ++++++++++++++++++++++++++++++++++++------
refs.h | 3 +
t/t3200-branch.sh | 34 +++++++++
5 files changed, 251 insertions(+), 27 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 4f5b5d5..71417fe 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -8,8 +8,9 @@ git-branch - List, create, or delete branches.
SYNOPSIS
--------
[verse]
-'git-branch' [-r] [-a] [-v] [--abbrev=<length>]
+'git-branch' [-r | -a] [-v [--abbrev=<length>]]
'git-branch' [-l] [-f] <branchname> [<start-point>]
+'git-branch' (-m | -M) [<oldbranch>] <newbranch>
'git-branch' (-d | -D) <branchname>...
DESCRIPTION
@@ -24,6 +25,12 @@ It will start out with a head equal to the one given as <start-point>.
If no <start-point> is given, the branch will be created with a head
equal to that of the currently checked out branch.
+With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
+If <oldbranch> had a corresponding reflog, it is renamed to match
+<newbranch>, and a reflog entry is created to remember the branch
+renaming. If <newbranch> exists, -M must be used to force the rename
+to happen.
+
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a ref log then the ref log will also be deleted.
@@ -46,6 +53,12 @@ OPTIONS
Force the creation of a new branch even if it means deleting
a branch that already exists with the same name.
+-m::
+ Move/rename a branch and the corresponding reflog.
+
+-M::
+ Move/rename a branch even if the new branchname already exists.
+
-r::
List the remote-tracking branches.
@@ -53,7 +66,7 @@ OPTIONS
List both remote-tracking branches and local branches.
-v::
- Show sha1 and subject message for each head.
+ Show sha1 and commit subjectline for each head.
--abbrev=<length>::
Alter minimum display length for sha1 in output listing,
@@ -70,6 +83,12 @@ OPTIONS
be given as a branch name, a commit-id, or a tag. If this option
is omitted, the current branch is assumed.
+<oldbranch>::
+ The name of an existing branch to rename.
+
+<newbranch>::
+ The new name for an existing branch. The same restrictions as for
+ <branchname> applies.
Examples
diff --git a/builtin-branch.c b/builtin-branch.c
index 3d5cb0e..3e206b9 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -10,8 +10,8 @@
#include "commit.h"
#include "builtin.h"
-static const char builtin_branch_usage[] =
-"git-branch (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | [-r | -a] [-v] [--abbrev=<length>] ";
+static const char builtin_branch_usage[] =
+ "git-branch (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | (-m | -M) [<oldbranch>] <newbranch> | [-r | -a] [-v [--abbrev=<length>]]";
static const char *head;
@@ -245,9 +245,37 @@ static void create_branch(const char *name, const char *start,
die("Failed to write ref: %s.", strerror(errno));
}
+static void rename_branch(const char *oldname, const char *newname, int force)
+{
+ char oldref[PATH_MAX], newref[PATH_MAX];
+ unsigned char sha1[20];
+
+ if (snprintf(oldref, sizeof(oldref), "refs/heads/%s", oldname) > sizeof(oldref))
+ die("Old branchname too long");
+
+ if (check_ref_format(oldref))
+ die("Invalid branch name: %s", oldref);
+
+ if (snprintf(newref, sizeof(newref), "refs/heads/%s", newname) > sizeof(newref))
+ die("New branchname too long");
+
+ if (check_ref_format(newref))
+ die("Invalid branch name: %s", newref);
+
+ if (resolve_ref(newref, sha1, 1, NULL) && !force)
+ die("A branch named '%s' already exists.", newname);
+
+ if (rename_ref(oldref, newref))
+ die("Branch rename failed");
+
+ if (!strcmp(oldname, head) && create_symref("HEAD", newref))
+ die("Branch renamed to %s, but HEAD is not updated!", newname);
+}
+
int cmd_branch(int argc, const char **argv, const char *prefix)
{
int delete = 0, force_delete = 0, force_create = 0;
+ int rename = 0, force_rename = 0;
int verbose = 0, abbrev = DEFAULT_ABBREV;
int reflog = 0;
int kinds = REF_LOCAL_BRANCH;
@@ -277,6 +305,15 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
force_create = 1;
continue;
}
+ if (!strcmp(arg, "-m")) {
+ rename = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-M")) {
+ rename = 1;
+ force_rename = 1;
+ continue;
+ }
if (!strcmp(arg, "-r")) {
kinds = REF_REMOTE_BRANCH;
continue;
@@ -300,6 +337,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
usage(builtin_branch_usage);
}
+ if ((delete && rename) || (delete && force_create) ||
+ (rename && force_create))
+ usage(builtin_branch_usage);
+
head = xstrdup(resolve_ref("HEAD", head_sha1, 0, NULL));
if (!head)
die("Failed to resolve HEAD as a valid ref.");
@@ -311,6 +352,10 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
delete_branches(argc - i, argv + i, force_delete);
else if (i == argc)
print_ref_list(kinds, verbose, abbrev);
+ else if (rename && (i == argc - 1))
+ rename_branch(head, argv[i], force_rename);
+ else if (rename && (i == argc - 2))
+ rename_branch(argv[i], argv[i + 1], force_rename);
else if (i == argc - 1)
create_branch(argv[i], head, force_create, reflog);
else if (i == argc - 2)
diff --git a/refs.c b/refs.c
index 96ea8b6..479f18c 100644
--- a/refs.c
+++ b/refs.c
@@ -610,6 +610,29 @@ static int remove_empty_directories(char *file)
return remove_empty_dir_recursive(path, len);
}
+static int is_refname_available(const char *ref, const char *oldref,
+ struct ref_list *list, int quiet)
+{
+ int namlen = strlen(ref); /* e.g. 'foo/bar' */
+ while (list) {
+ /* list->name could be 'foo' or 'foo/bar/baz' */
+ if (!oldref || strcmp(oldref, list->name)) {
+ int len = strlen(list->name);
+ int cmplen = (namlen < len) ? namlen : len;
+ const char *lead = (namlen < len) ? list->name : ref;
+ if (!strncmp(ref, list->name, cmplen) &&
+ lead[cmplen] == '/') {
+ if (!quiet)
+ error("'%s' exists; cannot create '%s'",
+ list->name, ref);
+ return 0;
+ }
+ }
+ list = list->next;
+ }
+ return 1;
+}
+
static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char *old_sha1, int *flag)
{
char *ref_file;
@@ -643,29 +666,14 @@ static struct ref_lock *lock_ref_sha1_basic(const char *ref, const unsigned char
orig_ref, strerror(errno));
goto error_return;
}
- if (is_null_sha1(lock->old_sha1)) {
- /* The ref did not exist and we are creating it.
- * Make sure there is no existing ref that is packed
- * whose name begins with our refname, nor a ref whose
- * name is a proper prefix of our refname.
- */
- int namlen = strlen(ref); /* e.g. 'foo/bar' */
- struct ref_list *list = get_packed_refs();
- while (list) {
- /* list->name could be 'foo' or 'foo/bar/baz' */
- int len = strlen(list->name);
- int cmplen = (namlen < len) ? namlen : len;
- const char *lead = (namlen < len) ? list->name : ref;
-
- if (!strncmp(ref, list->name, cmplen) &&
- lead[cmplen] == '/') {
- error("'%s' exists; cannot create '%s'",
- list->name, ref);
- goto error_return;
- }
- list = list->next;
- }
- }
+ /* When the ref did not exist and we are creating it,
+ * make sure there is no existing ref that is packed
+ * whose name begins with our refname, nor a ref whose
+ * name is a proper prefix of our refname.
+ */
+ if (is_null_sha1(lock->old_sha1) &&
+ !is_refname_available(ref, NULL, get_packed_refs(), 0))
+ goto error_return;
lock->lk = xcalloc(1, sizeof(struct lock_file));
@@ -776,6 +784,121 @@ int delete_ref(const char *refname, unsigned char *sha1)
return ret;
}
+int rename_ref(const char *oldref, const char *newref)
+{
+ static const char renamed_ref[] = "RENAMED-REF";
+ unsigned char sha1[20], orig_sha1[20];
+ int flag = 0, logmoved = 0;
+ struct ref_lock *lock;
+ char msg[PATH_MAX*2 + 100];
+ struct stat loginfo;
+ int log = !stat(git_path("logs/%s", oldref), &loginfo);
+
+ if (S_ISLNK(loginfo.st_mode))
+ return error("reflog for %s is a symlink", oldref);
+
+ if (!resolve_ref(oldref, orig_sha1, 1, &flag))
+ return error("refname %s not found", oldref);
+
+ if (!is_refname_available(newref, oldref, get_packed_refs(), 0))
+ return 1;
+
+ if (!is_refname_available(newref, oldref, get_loose_refs(), 0))
+ return 1;
+
+ if (snprintf(msg, sizeof(msg), "renamed %s to %s", oldref, newref) > sizeof(msg))
+ return error("Refnames to long");
+
+ lock = lock_ref_sha1_basic(renamed_ref, NULL, NULL);
+ if (!lock)
+ return error("unable to lock %s", renamed_ref);
+ lock->force_write = 1;
+ if (write_ref_sha1(lock, orig_sha1, msg))
+ return error("unable to save current sha1 in %s", renamed_ref);
+
+ if (log && rename(git_path("logs/%s", oldref), git_path("tmp-renamed-log")))
+ return error("unable to move logfile logs/%s to tmp-renamed-log: %s",
+ oldref, strerror(errno));
+
+ if (delete_ref(oldref, orig_sha1)) {
+ error("unable to delete old %s", oldref);
+ goto rollback;
+ }
+
+ if (resolve_ref(newref, sha1, 1, &flag) && delete_ref(newref, sha1)) {
+ if (errno==EISDIR) {
+ if (remove_empty_directories(git_path("%s", newref))) {
+ error("Directory not empty: %s", newref);
+ goto rollback;
+ }
+ } else {
+ error("unable to delete existing %s", newref);
+ goto rollback;
+ }
+ }
+
+ if (log && safe_create_leading_directories(git_path("logs/%s", newref))) {
+ error("unable to create directory for %s", newref);
+ goto rollback;
+ }
+
+ retry:
+ if (log && rename(git_path("tmp-renamed-log"), git_path("logs/%s", newref))) {
+ if (errno==EISDIR) {
+ if (remove_empty_directories(git_path("logs/%s", newref))) {
+ error("Directory not empty: logs/%s", newref);
+ goto rollback;
+ }
+ goto retry;
+ } else {
+ error("unable to move logfile tmp-renamed-log to logs/%s: %s",
+ newref, strerror(errno));
+ goto rollback;
+ }
+ }
+ logmoved = log;
+
+ lock = lock_ref_sha1_basic(newref, NULL, NULL);
+ if (!lock) {
+ error("unable to lock %s for update", newref);
+ goto rollback;
+ }
+
+ lock->force_write = 1;
+ hashcpy(lock->old_sha1, orig_sha1);
+ if (write_ref_sha1(lock, orig_sha1, msg)) {
+ error("unable to write current sha1 into %s", newref);
+ goto rollback;
+ }
+
+ return 0;
+
+ rollback:
+ lock = lock_ref_sha1_basic(oldref, NULL, NULL);
+ if (!lock) {
+ error("unable to lock %s for rollback", oldref);
+ goto rollbacklog;
+ }
+
+ lock->force_write = 1;
+ flag = log_all_ref_updates;
+ log_all_ref_updates = 0;
+ if (write_ref_sha1(lock, orig_sha1, NULL))
+ error("unable to write current sha1 into %s", oldref);
+ log_all_ref_updates = flag;
+
+ rollbacklog:
+ if (logmoved && rename(git_path("logs/%s", newref), git_path("logs/%s", oldref)))
+ error("unable to restore logfile %s from %s: %s",
+ oldref, newref, strerror(errno));
+ if (!logmoved && log &&
+ rename(git_path("tmp-renamed-log"), git_path("logs/%s", oldref)))
+ error("unable to restore logfile %s from tmp-renamed-log: %s",
+ oldref, strerror(errno));
+
+ return 1;
+}
+
void unlock_ref(struct ref_lock *lock)
{
if (lock->lock_fd >= 0) {
diff --git a/refs.h b/refs.h
index cd1e1d6..ce73d5c 100644
--- a/refs.h
+++ b/refs.h
@@ -47,4 +47,7 @@ extern int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned
/** Returns 0 if target has the right format for a ref. **/
extern int check_ref_format(const char *target);
+/** rename ref, return 0 on success **/
+extern int rename_ref(const char *oldref, const char *newref);
+
#endif /* REFS_H */
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index acb54b6..afaa853 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -70,4 +70,38 @@ test_expect_success \
git-branch -d l/m &&
git-branch l'
+test_expect_success \
+ 'git branch -m m m/m should work' \
+ 'git-branch -l m &&
+ git-branch -m m m/m &&
+ test -f .git/logs/refs/heads/m/m'
+
+test_expect_success \
+ 'git branch -m n/n n should work' \
+ 'git-branch -l n/n &&
+ git-branch -m n/n n
+ test -f .git/logs/refs/heads/n'
+
+test_expect_failure \
+ 'git branch -m o/o o should fail when o/p exists' \
+ 'git-branch o/o &&
+ git-branch o/p &&
+ git-branch -m o/o o'
+
+test_expect_failure \
+ 'git branch -m q r/q should fail when r exists' \
+ 'git-branch q &&
+ git-branch r &&
+ git-branch -m q r/q'
+
+test_expect_success \
+ 'git branch -m s/s s should work when s/t is deleted' \
+ 'git-branch -l s/s &&
+ test -f .git/logs/refs/heads/s/s &&
+ git-branch -l s/t &&
+ test -f .git/logs/refs/heads/s/t &&
+ git-branch -d s/t &&
+ git-branch -m s/s s &&
+ test -f .git/logs/refs/heads/s'
+
test_done
--
1.4.4.1.gf0df
^ permalink raw reply related
* Re: [RFC] git-branch: add options and tests for branch renaming
From: Andy Whitcroft @ 2006-11-28 15:03 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano
In-Reply-To: <11647252603530-git-send-email-hjemli@gmail.com>
Lars Hjemli wrote:
> Extend git-branch with the following options:
>
> git-branch -m|-M [<oldbranch>] newbranch
>
> The -M variation is required to force renaming over an exsisting
> branchname.
>
> This also indroduces $GIT_DIR/RENAME_REF which is a "metabranch"
> used when renaming branches. It will always hold the original sha1
> for the latest renamed branch.
>
> Additionally, if $GIT_DIR/logs/RENAME_REF exists, all branch rename
> events are logged there.
>
> Finally, some testcases are added to verify the new options.
Ok, I have been feeling uneasy about rename and reflogs for a while now.
About removing reflogs too for that matter.
In my mind the ref log is about tracking what a ref points to. So I
want to be able to say "what was next, yesterday". Do I care if its not
there now? Perhaps I want a rename to just put a rename from in the top
of the new reflog and leave the old there.
Yep, no idea how we would clean them up with this model. But ...
^ permalink raw reply
* Re: [PATCH] Trim hint printed when gecos is empty.
From: Andy Parkins @ 2006-11-28 15:06 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0611281536230.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Tuesday 2006 November 28 14:40, Johannes Schindelin wrote:
> You are probably different than me. What with my track record, I _trust_
> my patches to be not perfect at all. Nevertheless, I commit here and now,
> and usually I regroup the commits into a nice patch (series) (AKA poor
> man's StGit).
I'm certainly not perfect, nor would I ever claim to be. Perhaps I have
misunderstood the purpose of the Signed-Off line. I had understood it was a
legal tool to trace the provenance of a patch - not to sign off on it being
bug free (which surely is impossible).
Since I know that I, and I alone wrote that patch, I can sign off on it
regardless of it being any good technically.
This is in agreement with my understanding of the
Documentation/SubmittingPatches file included with git.
"The sign-off is a simple line at the end of the explanation for
the patch, which certifies that you wrote it or otherwise have
the right to pass it on as a open-source patch."
> So I will never need something like you suggest. Having said that, if you
> think it is best for you to mark every commit as signed-off-by you, just
> add an alias:
>
> git repo-config --global alias.c "commit -s"
That requires that I introduce a new command; I want the existing command to
do The Right Thing. Also; I certainly wouldn't want it global, as I said in
my original message - this is a per-project choice. Some projects don't have
Signed-Off lines, so there is no point there.
Ideally, I'd be able to do
git repo-config alias.commit "commit -s"
Just as I can with shell commands.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Workflow example for remote repository use of GIT
From: Sean Kelley @ 2006-11-28 15:08 UTC (permalink / raw)
To: git
I have been trying to set-up a workflow for developers in my group
using GIT. I came up with this simplified flow. Do you all see any
problems with this approach?
Thanks,
Sean
Always work out of master
git checkout master
Getting The Latest Upstream Code into master
git pull origin master
Create a topic branch for your development work
git checkout -b <new topic branch name>
Do your development in the topic branch
edit/debug/test
Committing Changes
git commit -a
Switch back to master
git checkout master
Update the master branch from origin again
git pull origin master
Now Merge your topic branch
git pull . <topic branch to merge into current branch>
How do I push my changes to the original repository?
git push origin master
--
^ permalink raw reply
* Re: Show remote branches on gitweb
From: Jakub Narebski @ 2006-11-28 15:14 UTC (permalink / raw)
To: git
In-Reply-To: <ek7m6m$qqd$1@sea.gmane.org>
Jakub Narebski wrote:
> Jakub Narebski wrote:
>
>> Pazu wrote:
>>
>>> Is there any way to do it? I'm using git-svn to track a remote subversion
>>> repository, and it would be very nice to browse the history for a remote branch
>>> for which I didn't start a local branch yet.
>>
>> Planned, not implemented yet.
>
> The problem is that to implement it _well_ we have to get remotes, both
> $GIT_DIR/remotes and config remote.xxx, info. And the latter (config
> remotes info) needs config parsing, something we lack.
We could simplify things, and assume that remote name is _never_
hierarchical, so that remote branches names are:
remotes/<remote>/<branch>
where <remote> does not contain '/'.
Additional problem is for "summary" view: should we limit number of heads
per remote, should we sort heads inside remote, or should we also sort
remotes, or should we sort remotes by time without grouping into repos?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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