* [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Shawn O. Pearce @ 2008-10-22 15:42 UTC (permalink / raw)
To: git
My "bundle related secret project" was released yesterday by Google
as part of the Android open source release event. (I've mentioned
it before on-list in the context of a modified "git status" output.)
Google developed two tools, repo and Gerrit, and open sourced them
under the Apache License:
http://android.git.kernel.org/?p=tools/repo.git
http://android.git.kernel.org/?p=tools/gerrit.git
git://android.git.kernel.org/tools/repo.git
git://android.git.kernel.org/tools/gerrit.git
repo is a Python application to bind together Git repositories,
something like "git submodule", except it can track a project's
branch rather than a specific Git commit. repo is also able to
natively import a tarball or zip file and use it to initialize a
repository from an upstream source, then apply git based changes
on top of that tarball. In other words, repo is (more or less)
built to manage an OS distribution, in Git.
Gerrit is a web based code review system, forked off the open
sourced Rietveld code review system. Gerrit runs on the highly
scaleable Google App Engine platform, but probably could be ported
to an open-source MySQL or PostgreSQL backend if people really
wanted to do that.
You can read some more of how Android has applied these tools to
its development process here:
http://source.android.com/download
http://source.android.com/submit-patches/workflow
http://source.android.com/download/using-repo
Although the current tool documentation is only on the Android
site, both the repo and Gerrit tools are not specific to Android
and are designed to be applied to any project that wants to use a
similar process.
repo and Gerrit are actually developed with themselves. You can
use repo to fetch repo:
curl http://android.git.kernel.org/repo >~/bin/repo
chomd a+x ~/bin/repo
mkdir myrepo
cd myrepo
repo init -u git://android.git.kernel.org/tools/manifest.git
repo sync
The "git status" output I was talking about before is the "repo
status" subcommand, e.g.:
$ echo '# test' >>repo/repo ; # modify a tracked file
$ repo status
project repo/ (*** NO BRANCH ***)
-m repo
--
Shawn.
^ permalink raw reply
* Re: error: packfile while git fsck
From: Nicolas Ferre @ 2008-10-22 15:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0810221049340.26244@xanadu.home>
Nicolas Pitre :
> On Wed, 22 Oct 2008, Nicolas Ferre wrote:
>
>> Hi all,
>> (please cc me on response)
>>
>> I am facing error during git status & git fsck on my tree.
>> This tree is cloned from various linux kernel trees.
>>
>> Here are a sample of the error I see :
>>
>> $ git fsck
>> error: packfile
>> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not
>> match index
>> error: packfile
>> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be
>> accessed
> [...]
>
> What git version?
$ git --version
git version 1.5.3.7
Kind regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Johannes Schindelin @ 2008-10-22 15:21 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Haberman, gitster, git
In-Reply-To: <20081022125149.GA17092@coredump.intra.peff.net>
Hi,
On Wed, 22 Oct 2008, Jeff King wrote:
> On Wed, Oct 15, 2008 at 02:44:36AM -0500, Stephen Haberman wrote:
>
> > + if [ "$fast_forward" == "t" ]
>
> This one even fails on my Linux box. :) "==" is a bash-ism.
Did we not also prefer "test" to "["?
Ciao,
Dscho
^ permalink raw reply
* Re: Start git svn clone at specific revision for cloning subprojects in large svn repositories?
From: Michael J Gruber @ 2008-10-22 15:08 UTC (permalink / raw)
To: Jeff Kowalczyk; +Cc: git
In-Reply-To: <pan.2008.10.22.15.00.21.403423@yahoo.com>
Jeff Kowalczyk venit, vidit, dixit 10/22/08 17:00:
> I would like to git svn clone subprojects from a large community
> subversion repository (plone collective).
>
> The repository is currently at 74K commits, but subprojects of interest
> are typically much more recent, and their initial import revision is known.
>
> I would like to avoid a) unnecessary traffic to the svn server and b)
> the very long delay in git svn cloning these subprojects.
>
> Is there a way to specfiy a starting revision to git svn clone?
Your friendly man page provider says:
-r <ARG>, --revision <ARG>
Used with the fetch command.
This allows revision ranges for partial/cauterized history to
be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric
ranges), $NUMBER:HEAD, and BASE:$NUMBER are all supported.
This can allow you to make partial mirrors when running
fetch; but is generally not recommended because history
will be skipped and lost.
Usage of "Scroll Down" is strongly advised when viewing git help svn ;)
Michael
P.S.: It works nicely, don't mind the warning in the man page if you
know the start rev for sure.
^ permalink raw reply
* Re: Start git svn clone at specific revision for cloning subprojects in large svn repositories?
From: Jacob Helwig @ 2008-10-22 15:07 UTC (permalink / raw)
To: Jeff Kowalczyk; +Cc: git
In-Reply-To: <pan.2008.10.22.15.00.21.403423@yahoo.com>
On Wed, Oct 22, 2008 at 08:00, Jeff Kowalczyk <jtk@yahoo.com> wrote:
> I would like to git svn clone subprojects from a large community
> subversion repository (plone collective).
>
> The repository is currently at 74K commits, but subprojects of interest
> are typically much more recent, and their initial import revision is known.
>
> I would like to avoid a) unnecessary traffic to the svn server and b)
> the very long delay in git svn cloning these subprojects.
>
> Is there a way to specfiy a starting revision to git svn clone?
>
> Thanks.
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Try git svn init, then git svn fetch --revision <revision#>:HEAD.
This is what I use for some of our larger projects at work.
^ permalink raw reply
* Start git svn clone at specific revision for cloning subprojects in large svn repositories?
From: Jeff Kowalczyk @ 2008-10-22 15:00 UTC (permalink / raw)
To: git
I would like to git svn clone subprojects from a large community
subversion repository (plone collective).
The repository is currently at 74K commits, but subprojects of interest
are typically much more recent, and their initial import revision is known.
I would like to avoid a) unnecessary traffic to the svn server and b)
the very long delay in git svn cloning these subprojects.
Is there a way to specfiy a starting revision to git svn clone?
Thanks.
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-22 14:59 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Peter Harris, git
In-Reply-To: <48FDF28A.9060606@xiplink.com>
Marc Branchaud venit, vidit, dixit 10/21/08 17:17:
> I believe git lets you track the origin's _branches_ not the origin's
> _remotes_. I don't think --mirror does what I'm looking for, because
> (side effects aside) it only deals with branches, not remotes.
>
> I find myself getting confused, and I think it's because the files in
> .git/refs/remotes/ are indeed tracking branches on remote repositories.
> So I think our conversation gets a bit circular because our ideas of a
> "remote" differ.
Yes, I think there are multiple uses:
- a remote repository (referenced to by an URL)
- a remote config (as created by git remote add)
- a remote branch (a branch in your local repo which is a copy of a
branch in a remote repo; stored under refs/remotes, never to be modified
locally)
- a (remote) tracking branch (a local branch which is set up to pull
from a remote branch by default)
Only the first of these 4 is something resides "remotely". Of course,
"remote URL" could be a path on the local file system or even ".".
> "git remote add" does two things (maybe more?): It adds a [remote]
> section to the .git/config file, and it adds a branch reference in
> .git/refs/remotes/.
Yes.
> I think what I'd like is for the clone to be able
> to obtain both these things from the origin. The reason I think it's
> useful is that it would let the clone pull directly from the origin's
> remote repositories, without having to directly specify the remote
> repository's URL and branch name.
>
> Fundamentally, I'm looking to do exactly
>
> clone/$ git pull -s subtree /path/to/ThingOne master
>
> i.e. pull stuff from one of main's remotes directly into the clone. But
> I want to replace the "/path/to/ThingOne master" part with something
> that means "use whatever URL and branch name was defined in the origin
> for this remote".
>
> My questions are: Am I right in thinking this is desirable?
I've got the strong impression you desire it...
Seriously, it seems desirable in cases where the remote URL changes
frequently; say, because the upstream maintainer (maintainer of
ThingOne) gets hit by a bus frequently, or walks the wrong streets in LA
at the wrong time of the day. (I guess my seriousness ended with the
";".) Clones would follow those changes transparently then (if that
feature existed).
> Is there
> already some way to do this?
None that I know of.
> If not, is it something worth
> implementing? (I'm happy to roll up my own sleeves here...)
First you should decide whether it is worth for you. Comments on the
list tend to kick in once people see a proposed implementation. A viable
strategy could be, mimicking git submodule behaviour in part:
- Implement "git remote export reponame" which takes an existing remote
config from .git/config, writes it to .gitremotes and checks in (or
better: stages for commit) the file .gitremotes [you would use this on main]
- Implement "git remote import" which reads the file .gitremotes and
adds remote config to .git/config. [you would use this on clones]
- Change "git remote update" to take updates to .gitremotes into account
before doing its usual routine (perhaps based on a config with default
off, or a command line option, or better both)
Downside is that .gitremotes is tracked would show up as a file in the
repo, but I can't come up with a better way which is as simple as the
above. .gitremotes could be stored in a specially named branch, though.
> I hope that clarifies things. Sorry for taking so long to get here!
Don't worry. I take partial blame ;)
And thanks for trying to match up your workflow with git.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-22 14:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810211856090.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 10/22/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I propose this change in semantics:
>
> - setup_git_directory_gently(): rename to discover_git_directory(),
> and avoid any chdir() at all.
> - setup_git_directory(): keep the semantics that it chdir()s to the
> worktree, or to the git directory for bare repositories.
>
> Using _gently() even for RUN_SETUP builtins should solve the long standing
> pager problem, too.
Also, from [1] may be only set default git_dir in setup_git_env()
after setup_git_directory() has been called and before
setup_work_tree() is called (if any)? If not, die().
[1] http://article.gmane.org/gmane.comp.version-control.git/98849
--
Duy
^ permalink raw reply
* Re: error: packfile while git fsck
From: Nicolas Pitre @ 2008-10-22 14:52 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: git
In-Reply-To: <48FF337F.3050505@atmel.com>
On Wed, 22 Oct 2008, Nicolas Ferre wrote:
> Hi all,
> (please cc me on response)
>
> I am facing error during git status & git fsck on my tree.
> This tree is cloned from various linux kernel trees.
>
> Here are a sample of the error I see :
>
> $ git fsck
> error: packfile
> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not
> match index
> error: packfile
> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be
> accessed
[...]
What git version?
> Did I do something wrong (merging files while fetching) ?
Unlikely.
Nicolas
^ permalink raw reply
* error: packfile while git fsck
From: Nicolas Ferre @ 2008-10-22 14:06 UTC (permalink / raw)
To: git
Hi all,
(please cc me on response)
I am facing error during git status & git fsck on my tree.
This tree is cloned from various linux kernel trees.
Here are a sample of the error I see :
$ git fsck
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
[..]
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
dangling blob fe130d58453393f15e0db82bca18f35998689a87
dangling commit 2515ddc6db8eb49a79f0fe5e67ff09ac7c81eab4
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
dangling commit 6bb7a935489dab20802dde6c2cb7d8582f4849bf
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
dangling commit 4aba41ea8bdc1b475861f5e5c1649ab20251090c
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
[..]
$ git verify-pack .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
nferre@bendor:linux-2.6-arm > git verify-pack .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
fatal: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
What can I do to recover my git archive ?
Did I do something wrong (merging files while fetching) ?
Is it related to a known issue (I cannot figure out if it is
after some googling) ?
Thanks for your help. Regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: Does a `git pull' write to the origin repository in any way?
From: Brett Ryan @ 2008-10-22 14:27 UTC (permalink / raw)
To: Marc Weber, git
In-Reply-To: <20081022132517.GM3988@gmx.de>
Thanks Marc. I agree the dev cycle is a little strange, though we're
still using a 4GL environment (Progress) from the 70's where all the
developers have no prior experience to version control except for
renaming files to ${name}.yyyymmdd.
My apologies for being a little light headed I've only been using git
for about a week now, currently I'm the main merger for CVS and
looking for an alternative. First impressions of `git' to me are
fantastic and it seems to fit right, what I need to do is figure out a
good dev cycle that my peers can use as they're all used to working
int he same directory and just simply yelling out to each other "I'm
about to edit file {x}", making me cringe each time.
Anyway Marc your answer was all I'm after, it could have been
something I goofed, just needed clarification that a pull wasn't going
to touch the rep that the pull is pulling from.
Thanks,
-Brett
On Thu, Oct 23, 2008 at 12:25 AM, Marc Weber <marco-oweber@gmx.de> wrote:
> On Wed, Oct 22, 2008 at 08:00:11PM +1100, Brett Ryan wrote:
>> Greetings, the reason I ask this question is because my pattern of
>> development is to create local source git repositories on my home
>> directory, then pull them to the central location. I found myself
>> getting the error `unable to create temporary sha1 filename
>> .git/objects/11: File exists' which after investigation found that
>> there were paths in `.git/objects/' owned by root which is who I use
>> to do the pull from my home directory using sudo.
> Aeh.. about which repo are you talking here? I guess it's not the one
> owned by root because otherwise this would be normal..
>
> Hi Brett, I'm not sure where the problem comes form. But I feel your dev
> cycle is kind of wired.
> If you can login as root using ssh you can also do it the "normal" (?)
> way:
>
> # user dir
> git remote add root_repo ssh://root@localhost/path-to-root-repo
> git pull root_repo # then resolve conflicts if any
> git push root_repo # update the root repo
>
> This way you always have conflicts in your local repo and never on the
> root one which is preferable (IMHO)..
>
> git-fetch doesn't list a way to access another repo by "su(do)" which
> might be the best way here ? This could be convinient because you
> would'nt have to setup an extra group to access the same repo as root
> and user (?)
>
> You're right that git pull *should not* modify any files from the repo
> its pulling from.. But I don't know enough about git internals to say
> more about this. All I know is that git clone might have created some
> hardlinks.. But I'm not sure how this interfers with file permissions.
>
> I hope someone else can give a more accurate reply.
>
> Marc Weber
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-22 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810211856090.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 10/22/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I propose this change in semantics:
>
> - setup_git_directory_gently(): rename to discover_git_directory(),
> and avoid any chdir() at all.
> - setup_git_directory(): keep the semantics that it chdir()s to the
> worktree, or to the git directory for bare repositories.
>
> Using _gently() even for RUN_SETUP builtins should solve the long standing
> pager problem, too.
One more thing: "git foo -h" with RUN_SETUP won't run if repository is
not found. Maybe just drop RUN_SETUP and let subcommands call
setup_git_directory()
--
Duy
^ permalink raw reply
* Re: git add --patch newfile doesn't add newfile to cache ?
From: Jeff King @ 2008-10-22 13:29 UTC (permalink / raw)
To: Marc Weber; +Cc: git
In-Reply-To: <20081022131232.GL3988@gmx.de>
On Wed, Oct 22, 2008 at 03:12:32PM +0200, Marc Weber wrote:
> > sub patch_update_cmd {
> > + my @new = list_untracked();
> > + if (@new) {
> > + system(qw(git add -N), @new)
> > + and die "git add reported failure";
> > + }
> > +
>
>
> I've tried the patch. However I'm not fully satisified.
> I often use --patch to have another second look at each change to be
> committed. Your patch adds new files to the cache silently without
> giving the user the change to omit or edit the patch. But exatly that's
> the reason I'm using --patch. So maybe I can work on this in some days..
> Maybe I've also injected those lines into the wrong git version
> (1.6.0.2.GIT)
Yes, you need to use the current 'master' branch for the "-N" feature.
The point of "-N" is to say "this is a file I want to track, but don't
add any contents yet." So it does your part 1:
> 1) when using git add --patch untracked-file the user should be
> given the default patch view (only containing + lines)
> so that he can use edit to only commit parts of the file in the
> usual way. (I guess this is similar to having used git add -N
> before, I haven't tried yet)
But not your part 2:
> 2) if he wants to skip the entire patch / file nothing should be
> added to the index.
If you add _no_ contents, you still end up with the "this is a file I
want to track" part, but with no contents. And I agree it should stage
nothing, which is why this is an unsatisfactory solution (and why I
didn't clean up the patch and send it to Junio for inclusion).
-Peff
^ permalink raw reply
* Re: Does a `git pull' write to the origin repository in any way?
From: Marc Weber @ 2008-10-22 13:25 UTC (permalink / raw)
To: git
In-Reply-To: <a65d095e0810220200q42936427o917cdac067d04135@mail.gmail.com>
On Wed, Oct 22, 2008 at 08:00:11PM +1100, Brett Ryan wrote:
> Greetings, the reason I ask this question is because my pattern of
> development is to create local source git repositories on my home
> directory, then pull them to the central location. I found myself
> getting the error `unable to create temporary sha1 filename
> .git/objects/11: File exists' which after investigation found that
> there were paths in `.git/objects/' owned by root which is who I use
> to do the pull from my home directory using sudo.
Aeh.. about which repo are you talking here? I guess it's not the one
owned by root because otherwise this would be normal..
Hi Brett, I'm not sure where the problem comes form. But I feel your dev
cycle is kind of wired.
If you can login as root using ssh you can also do it the "normal" (?)
way:
# user dir
git remote add root_repo ssh://root@localhost/path-to-root-repo
git pull root_repo # then resolve conflicts if any
git push root_repo # update the root repo
This way you always have conflicts in your local repo and never on the
root one which is preferable (IMHO)..
git-fetch doesn't list a way to access another repo by "su(do)" which
might be the best way here ? This could be convinient because you
would'nt have to setup an extra group to access the same repo as root
and user (?)
You're right that git pull *should not* modify any files from the repo
its pulling from.. But I don't know enough about git internals to say
more about this. All I know is that git clone might have created some
hardlinks.. But I'm not sure how this interfers with file permissions.
I hope someone else can give a more accurate reply.
Marc Weber
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Jeff King @ 2008-10-22 13:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Ingo Molnar, git
In-Reply-To: <m3ljwgj3xy.fsf@localhost.localdomain>
On Wed, Oct 22, 2008 at 03:50:52AM -0700, Jakub Narebski wrote:
> About printing either forward (git-describe, e.g. v1.6.0.2-590-g67f6062)
> or backward (git-name-rev, e.g. tags/v1.6.0-rc2~8): you can use
> git-name-rev in filter mode (git log ... | git name-rev --stdin), or
> "git log --decorate", or '%d' in --pretty format specifier (this is very
> new thing).
The "--decorate" and "%d" code just decorates branch _tips_. My
impression is that he wanted to see the branch mentioned even if the
commit was not at the tip. It would be possible to extend this to print
name-rev output, but it would be computationally and memory-intensive, I
suspect.
-Peff
^ permalink raw reply
* Re: git add --patch newfile doesn't add newfile to cache ?
From: Marc Weber @ 2008-10-22 13:12 UTC (permalink / raw)
To: git
In-Reply-To: <20081020235049.GA23120@coredump.intra.peff.net>
On Mon, Oct 20, 2008 at 07:50:50PM -0400, Jeff King wrote:
> On Mon, Oct 20, 2008 at 04:36:36PM +0200, Marc Weber wrote:
>
> > Is this desired behaviour?
> > [...]
> > git init
> > echo test > test
> > git add --patch test
> > echo "running status, nothing has been added"
> > git status
>
> I think your example makes sense, but nobody ever really tried it
> before. [..]
I came across this use case because I'm lazy. eg
git add --patch file-to-be-committed-partly newfile
is shorter than
git add --patch file-to-be-committed-partly
git add newfile
> I use "git add -p" all the time, but almost always when I am
> adding a new file, I add the whole contents.
>
> I think there are two ways to go about fixing it:
>
> - in git-add--interactive.perl, the function patch_update_cmd
> explicitly looks at the list of modified files. It would have to
> also check for untracked files, which is easy. But we also need to
> keep track of which files are modified and which are untracked
> through the whole patching procedure, which is a bit more invasive.
>
> - the recently-added "git add -N" adds an empty file into the index,
> at which point we could add content in the normal way. So:
>
> git add -N test
> git add -p test
>
> should just work (but obviously requires two steps from the user).
> You could do something more automatic like the patch below, but I
> think the semantics aren't quite right. If you stage nothing for a
> newly added file, then you still end up with an empty version of the
> staged file in the index. I would expect the semantics to be:
>
> 1. if you stage any content, then the file is added to the index
> with that content
>
> 2. if you stage no content, then the file remains untracked
> ---
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> [...]
> sub patch_update_cmd {
> + my @new = list_untracked();
> + if (@new) {
> + system(qw(git add -N), @new)
> + and die "git add reported failure";
> + }
> +
I've tried the patch. However I'm not fully satisified.
I often use --patch to have another second look at each change to be
committed. Your patch adds new files to the cache silently without
giving the user the change to omit or edit the patch. But exatly that's
the reason I'm using --patch. So maybe I can work on this in some days..
Maybe I've also injected those lines into the wrong git version
(1.6.0.2.GIT)
May I try rewriting your semantics proposal to this ?
1) when using git add --patch untracked-file the user should be
given the default patch view (only containing + lines)
so that he can use edit to only commit parts of the file in the
usual way. (I guess this is similar to having used git add -N
before, I haven't tried yet)
2) if he wants to skip the entire patch / file nothing should be
added to the index.
Thanks for your reply.
Sincerly
Marc Weber
^ permalink raw reply
* Re: git archive
From: Deskin Miller @ 2008-10-22 13:08 UTC (permalink / raw)
To: kenneth johansson; +Cc: git
In-Reply-To: <gdmp0p$92r$1@ger.gmane.org>
On Wed, Oct 22, 2008 at 08:42:01AM +0000, kenneth johansson wrote:
> I was going to make a tar of the latest stable linux kernel.
> Done it before but now I got a strange problem.
>
> >git archive --format=tar v2.6.27.2
> fatal: Not a valid object name
I had the same thing happen to me, while trying to make an archive of Git.
Were you perchance working in a bare repository, as I was? I spent some time
looking at it and I think git archive sets up the environment in the wrong
order, though of course I never finished a patch so I'm going from memory:
After looking at the code again, I think the issue is that git_config is called
in builtin-archive.c:cmd_archive before setup_git_directory is called in
archive.c:write_archive. The former ends up setting GIT_DIR to be '.git' even
if you're in a bare repository. My coding skills weren't up to fixing it
easily; moving setup_git_directory before git_config in builtin-archive caused
last test of t5000 to fail: GIT_DIR=some/nonexistent/path git archive --list
should still display the archive formats.
Another vote for from me for the discussion carried on here:
http://article.gmane.org/gmane.comp.version-control.git/98800
Deskin Miller
^ permalink raw reply
* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Jeff King @ 2008-10-22 12:51 UTC (permalink / raw)
To: Stephen Haberman; +Cc: gitster, git
In-Reply-To: <759654ef1f1781cd2b102e21c6f972b065560398.1224055978.git.stephen@exigencecorp.com>
On Wed, Oct 15, 2008 at 02:44:36AM -0500, Stephen Haberman wrote:
> + if [ "$fast_forward" == "t" ]
This one even fails on my Linux box. :) "==" is a bash-ism.
-Peff
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 12:39 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano
In-Reply-To: <bb6f213e0810220232p2e7fe3daoa32f46fbe5bef2ac@mail.gmail.com>
On Wed, Oct 22, 2008 at 01:32:56PM +0400, Alexander Gavrilov wrote:
> From the output it seems that what fails is "-f cp1251 -t sjis" and
> "-f utf-8 -t sjis" (remember that blame --incremental produces its
Oh, indeed. Converting to and from utf-8 seems to work, but not between
cp1251 and sjis:
$ iconv -f SJIS -t UTF-8 sjis.txt | sed s/SJIS/UTF8/ >test &&
> cmp test utf8.txt && echo ok
ok
$ iconv -f UTF-8 -t SJIS utf8.txt | sed s/UTF8/SJIS/ >test &&
> cmp test sjis.txt && echo ok
ok
$ iconv -f SJIS -t CP1251 sjis.txt
Not supported SJIS to CP1251
$ iconv -f CP1251 -t SJIS cp1251.txt
Not supported CP1251 to SJIS
So I think it is simply a limitation of the platform with respect to the
particular encodings used. There is a similar problem in t3900, I think,
with EUCJP and ISO-2022-JP. I assume one _can_ install these encodings
for Solaris, but the admins of my box haven't done so (and this is a
production box that I can't ask for such things on).
> blame for some reason actually tries to convert to an entirely
> different encoding. If tests 4 and 5 pass, you can try adding
> --encoding=shift-jis to test 2 to check it.
Tests 2, 3, and 4 fail. Test 5 does pass.
-Peff
^ permalink raw reply
* Re: git history and file moves
From: Michael J Gruber @ 2008-10-22 12:38 UTC (permalink / raw)
To: Lin Ming; +Cc: Alex Riesen, git, Moore, Robert
In-Reply-To: <81b0412b0810220419q43f6985fs1c608e3d3cbcf8f3@mail.gmail.com>
Alex Riesen venit, vidit, dixit 10/22/08 13:19:
> 2008/10/22 Lin Ming <ming.m.lin@intel.com>:
>> I'm looking for a way to move files to a new directory and have the
>> full history follow the file automatically. Is this possible?
>>
>> I know about --follow, but I want the history to just follow the file
>> transparently. ...
>
> Of all Git tools, what does not do this "transparently" or "automatically"?
> How more transparent do you imagine this?
> What do you think should follow what?
>
> I ask, because it is hard to understand what exactly is it you're missing:
> merge support (which we have), git log listing the files as copied/renamed
> (which is what --follow is for, and the suggestion for you is to make an
> alias or something), git blame (ever looked at git gui blame?) or gitk
> (which follows renames in default configuration)
>
>> Also, we have a git web interface and we want the full
>> history for the moved files to be available.
>
> It is available. Whether it is shown is another question. git-web can
> be improved (or just configured?)
By default, gitweb uses "-M" for diff. You can specify all options (-C,
-CC, -B) using "@diff_opts" in the config file for gitweb.cgi - if that
is what you are using. Is it?
Anyways, using default configs for git log and gitweb.cgi both of them
show the full history (renames, history before and after) for me here,
using current git (1.6.0.3.514.g2f91b). What is your setup?
Michael
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-22 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Andreas Ericsson, git
In-Reply-To: <7vd4htwp6v.fsf@gitster.siamese.dyndns.org>
My apologies!! I hit send button by mistake before message was
complete. Please, see below a completed version.
--Leo--
On 10/21/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > 2008/10/21 Junio C Hamano <gitster@pobox.com>:
> >> "Leo Razoumov" <slonik.az@gmail.com> writes:
> >>
> >>> Even though the old behavior is "long established", it introduces
> >>> unnecessary ambiguity. If I have two repos
> >>> ...
> >>
> >> Of course. Now you know why people don't name such a pair of repositories
> >> like that ;-).
> >
> > FWIW, I support Leo on that. The "established" behavior is stupid.
>
>
> I am not inclined to respond to such an emotional argument. On the other
> hand, it is fair to say that the existing behaviour is established,
> because it is backed by a long history, which you can objectively verify.
>
> If you think about it deeper, you will realize that it is not even clear
> if it is "stupid".
>
> More importantly, the behaviour is consistent with the way how "git fetch"
> and "git clone" DWIMs the repository name by suffixing .git when the input
> lacks it. And this DWIMmery comes from the expectations that:
>
> (1) people name their repository project.git; and
>
> (2) people like using and seeing short names (iow, "clone
> git://$somewhere/project" is preferred over "clone
> git://$somewhere/project.git");
>
> If a repository whose real location is git://$somewhere/project.git is
> cloned/fetched as git://$somewhere/project by people, recording the merge
> source using the shorter name used by people to fetch from it is more
> consistent. The patch breaks this consistency [*1*].
>
> What is clear is that you would confuse yourself if you have two
> repositories A and A.git next to each other, and that is primarily because
> it breaks the above expectation.
>
> git core-level rarely imposes such policies, but what Porcelains do is a
> different matter.
>
> Hence the suggestion: don't do it.
>
> [Footnote]
>
> *1* It would be a different matter if the patch at the same time removed
> the fetch/clone DWIMmery. At least such a patch would be internally self
> consistent.
>
I think this discussion went in the direction of "correct" versus
"convent". I, personally, will choose correct over convenient any
time. Different people use git for different projects and their
expectations differ in this regard. In my case
after I do "git clone Foo.git" I get "Foo" repo side-by-side with
"Foo.git" and the ambiguity becomes apparent.
Regarding your footnote *1*. I agree with your suggestions and I can
improve the patch in the following way:
(P1) Fetch/clone messages/records will refer to the source/destination
repos by their complete names without stripping off any parts of the name.
(P2) Searching for a source repo, clone/fetch will first try an exact
match and if it fails it will remove/add ".git" suffix as needed and retry.
Item (P2) will provide the convenience, while item (P1) still
guarantees correctness.
Please, let me know if such approach is more satisfactory.
--Leo--
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-22 11:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Andreas Ericsson, git
In-Reply-To: <7vd4htwp6v.fsf@gitster.siamese.dyndns.org>
On 10/21/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > 2008/10/21 Junio C Hamano <gitster@pobox.com>:
> >> "Leo Razoumov" <slonik.az@gmail.com> writes:
> >>
> >>> Even though the old behavior is "long established", it introduces
> >>> unnecessary ambiguity. If I have two repos
> >>> ...
> >>
> >> Of course. Now you know why people don't name such a pair of repositories
> >> like that ;-).
> >
> > FWIW, I support Leo on that. The "established" behavior is stupid.
>
>
> I am not inclined to respond to such an emotional argument. On the other
> hand, it is fair to say that the existing behaviour is established,
> because it is backed by a long history, which you can objectively verify.
>
> If you think about it deeper, you will realize that it is not even clear
> if it is "stupid".
>
> More importantly, the behaviour is consistent with the way how "git fetch"
> and "git clone" DWIMs the repository name by suffixing .git when the input
> lacks it. And this DWIMmery comes from the expectations that:
>
> (1) people name their repository project.git; and
>
> (2) people like using and seeing short names (iow, "clone
> git://$somewhere/project" is preferred over "clone
> git://$somewhere/project.git");
>
> If a repository whose real location is git://$somewhere/project.git is
> cloned/fetched as git://$somewhere/project by people, recording the merge
> source using the shorter name used by people to fetch from it is more
> consistent. The patch breaks this consistency [*1*].
>
> What is clear is that you would confuse yourself if you have two
> repositories A and A.git next to each other, and that is primarily because
> it breaks the above expectation.
>
> git core-level rarely imposes such policies, but what Porcelains do is a
> different matter.
>
> Hence the suggestion: don't do it.
>
> [Footnote]
>
> *1* It would be a different matter if the patch at the same time removed
> the fetch/clone DWIMmery. At least such a patch would be internally self
> consistent.
>
I think this discussion went in the direction of "correct" versus
"convent". I, personally, will choose correct over convenient any
time. Different people use git for different projects and their
expectations differ in this regard. In my case
after I do "git clone Foo.git" I get "Foo" repo side-by-side with
"Foo.git" and the ambiguity becomes apparent.
Regarding your footnote *1*. I agree with your suggestions and I can
improve the patch in the following way:
(1) Fetch/clone messages/comments will refer to the source/destination
repos by their complete names without stripping off any parts
(2) Searching for a source repo, clone/fetch will first try an exact
match and if it fails it will remove/add ".git" suffix and
^ permalink raw reply
* Re: git history and file moves
From: Alex Riesen @ 2008-10-22 11:19 UTC (permalink / raw)
To: Lin Ming; +Cc: git, Moore, Robert
In-Reply-To: <1224640967.14280.0.camel@minggr.sh.intel.com>
2008/10/22 Lin Ming <ming.m.lin@intel.com>:
> I'm looking for a way to move files to a new directory and have the
> full history follow the file automatically. Is this possible?
>
> I know about --follow, but I want the history to just follow the file
> transparently. ...
Of all Git tools, what does not do this "transparently" or "automatically"?
How more transparent do you imagine this?
What do you think should follow what?
I ask, because it is hard to understand what exactly is it you're missing:
merge support (which we have), git log listing the files as copied/renamed
(which is what --follow is for, and the suggestion for you is to make an
alias or something), git blame (ever looked at git gui blame?) or gitk
(which follows renames in default configuration)
> Also, we have a git web interface and we want the full
> history for the moved files to be available.
It is available. Whether it is shown is another question. git-web can
be improved (or just configured?)
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Jakub Narebski @ 2008-10-22 10:50 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081022061730.GA5749@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> Git recently started printing the branch name when creating commits:
>
> [irq/urgent]: created 3786fc7: "irq: make variable static"
>
> very nice idea IMO! Having it all on one line allows me to double-check
> that i indeed queued up a patch in the intended topic branch. Had it
> read:
>
> [irq/urgent]: created 3786fc7: "printk: make variable static"
>
> i'd have noticed the mistake immediately.
>
> this welcome enhancement made me remember of three usage problems i had
> with Git recently:
[...]
About printing either forward (git-describe, e.g. v1.6.0.2-590-g67f6062)
or backward (git-name-rev, e.g. tags/v1.6.0-rc2~8): you can use
git-name-rev in filter mode (git log ... | git name-rev --stdin), or
"git log --decorate", or '%d' in --pretty format specifier (this is very
new thing).
You might be also interested in --abbrev-commit (when used with
--pretty=oneline format), and --graph option to git-log (or
git-show-branch). The "(--merged | --no-merged | --contains) [<commit>]"
options to git-branch might be also of interest...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Ingo Molnar @ 2008-10-22 9:58 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48FEF868.2010802@op5.se>
* Andreas Ericsson <ae@op5.se> wrote:
> Ingo Molnar wrote:
>> * Andreas Ericsson <ae@op5.se> wrote:
>>
>>> I imagine you'd want to use it to find out which branches you can (or
>>> can't) merge, and in that case you need to know about all the topics
>>> which have the commit. Assuming you don't go crazy cherry-picking and
>>> criss-cross merging, it should only list a few. The output is not as
>>> fancy as below, but it should be faster than the appended script (by
>>> several orders of magnitude).
>>
>> i solved that particular problem quite well, based on suggestions in a
>> thread earlier on the git-list. I'm using git branch --no-merged:
>>
>> earth4:~/tip> time todo-merge-all
>> merging the following updated branches:
>> merging linus ... ... merge done.
>>
>> real 0m2.865s
>> user 0m2.580s
>> sys 0m0.228s
>>
>> that work step used to be over a minute! There are 233 topic branches
>> at the moment and 18 integration branches. Kudos for making this go
>> really fast in 1.6.0.
>>
>> the thing i'm after is to see the originator branch of changes. "git
>> name-rev" was suggested by Santi Béjar in this thread and that is
>> exactly what i need - i'll try to integrate it into some git-log-ish
>> output tool.
>>
>> One thing i noticed is that 'git name-rev' can be quite slow for
>> certain commits:
>>
>> earth4:~/tip> time git name-rev 948f984
>> 948f984 tags/tip-safe-poison-pointers-2008-05-26_08_52_Mon~1
>>
>> real 0m2.181s
>> user 0m2.068s
>> sys 0m0.092s
>>
>> Which seems natural since it might have to dive back into history and
>> cross-reference it to all names. (there's 400 branches and 450 tags in
>> this tree, so i'm certainly pushing things!)
>>
>> But if i use that in my git-log-line summary tool it might become
>> quadratic overhead (or worse) very quickly, with minutes of runtime.
>>
>
> What's the timing for "git branch --contains 948f984" ?
>
> "git name-rev" parses a lot more just to be able to print a pretty
> short-name (the reversed "git describe") for you to use.
it takes much longer:
earth4:~/tip> time git branch --contains 948f984
[... 44 branches ...]
real 0m9.596s
user 0m9.151s
sys 0m0.218s
Ingo
^ 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