* How to push changes from clone back to master
From: Simon C @ 2010-01-08 21:28 UTC (permalink / raw)
To: git
I created master branch in git:
mkdir git_master;
cd git_master
git init
git add .
git commit
create a clone
git clone . ../git_clone1
create newfile
git add newfile
git commit .
then try to propagate changes to master
git push
it gave me some warning, and subsequent git push says everything is up to
date.
but I do not see the new file under git_master
--
View this message in context: http://n2.nabble.com/How-to-push-changes-from-clone-back-to-master-tp4275010p4275010.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Trouble with 'make prefix=/usr info'
From: Chris Johnsen @ 2010-01-08 21:14 UTC (permalink / raw)
To: Craig Moore; +Cc: Michael J Gruber, git
In-Reply-To: <d4133e471001060432v38a3f910qb27b9e77f4c1aa8b@mail.gmail.com>
On 2010 Jan 6, at 06:32, Craig Moore wrote:
> I've isolated the problem, and its coming from this command:
>
> ================================
> $ docbook2x-texi user-manual.xml --encoding=UTF-8 --to-stdout
>> user-manual.texi++
> Usage: jw [<options>] <sgml_file>
> where <options> are:
> -f|--frontend <frontend>: Specify the frontend (source format)
> (default is docbook)
> -b|--backend <backend>: Specify the backend (destination
> format)
> (default is html)
> -c|--cat <file>: Specify an extra SGML open catalog
> -n|--nostd: Do not use the standard SGML open
> catalogs
> -d|--dsl <file>|default|none: Specify an alternate style sheet
> (default is to use the default
> stylesheet)
> -l|--dcl <file>: Specify an alternate SGML declaration
> (usual ones like xml.dcl get detected
> automatically)
> -s|--sgmlbase <path>: Change base directory for SGML
> distribution
> (usually /usr/share/sgml)
> -p|--parser <program>: Specify the parser if several are
> installed
> (jade or openjade)
> -o|--output <directory>: Set output directory
> -u|--nochunks: Output only one big file
> (overrides the stylesheet settings)
> -i|--include <section>: Specify a SGML marked section to
> include
> (should be marked as "ignore" in
> the SGML text)
> -w|--warning <warning_type>|list: Control warnings or display the
> allowed warning types
> -e|--errors <error_type>|list: Control errors or display the allowed
> error types
> -h|--help: Print this help message and exit
> -V <variable[=value]>: Set a variable
> -v|--version: Print the version and exit
>
> $ docbook2x-texi --version
> DocBook-utils version 0.6.14 (jw version 1.1)
> ================================
>
> As you can see, I'm using DocBook-utils version 0.6.14 (jw version
> 1.1), and it doesn't list '--encoding=UTF-8 --to-stdout' in its
> options list. I'm guessing I've got the wrong version or type
> installed? Is there another which I should be using?
>
> Thanks for your help,
> Craig
>
I have previously used docbook2texi from docbook2X 0.8.8 by setting
DOCBOOK2X_TEXI for 'make info'.
<http://docbook2x.sourceforge.net/>
It needed a non-released patch to understand the combination of "--to-
stdout" and "--encoding=", though:
<http://docbook2x.cvs.sourceforge.net/viewvc/docbook2x/docbook2X/
perl/db2x_texixml.pl?r1=1.49&r2=1.50>
Alternatively, it is possible to work-around the failure of --stdout
with a wrapper script, but the patch is easy enough to apply.
--
Chris
^ permalink raw reply
* Idea: global git object cache
From: Avery Pennarun @ 2010-01-08 21:05 UTC (permalink / raw)
To: Git Mailing List
Hi all,
One thing I find curious about git is how objects mostly aren't shared
between multiple repositories on the local system. For example, if I
do:
git clone git://git.kernel.org/pub/scm/git/git.git git1
git clone git://git.kernel.org/pub/scm/git/git.git git2
Then I end up downloading the same objects from kernel.org *twice*.
If I use --reference on the second clone, then I can avoid
re-downloading all the objects, and it's much faster.
Unfortunately, I have to provide that option by hand, which is a
problem for git-submodule: it goes out to clone someone else's
repository automatically and doesn't know how to guess a value for
--reference. Another thing I commonly want to do with submodules is
to rm -rf the submodule's files, eg. because I change branches and git
doesn't clean it automatically. But then when I switch branches back
to the one with the submodule, git wants to go re-download the
submodule *again*. Redoing the checkout makes sense to me (just as
git deletes/recreates files when I normally switch branches) but
re-downloading seems silly.
So here's my suggestion to minimize downloads in a pretty easy way:
- whenever git creates a packfile in any repo (eg. during git gc or
git fetch), make an *extra* hardlink of it into
~/.gitcache/objects/pack.
- whenever git is considering which objects it does/doesn't currently
have, also consider the packs in ~/.gitcache/objects/pack (ie. using
the git/objects/alternates mechanism). If one of the packs qualifies,
hardlink it into the current repo. Maybe give it a .keep file to
indicate that it's counterproductive to repack this pack.
- after git deletes a packfile in any repo (eg. during git gc), check
the link count of that pack in ~/.gitcache/objects/pack; if it's now
down to just 1, there are no other users of the pack, so delete it
there too. You would also need to prune the cachedir occasionally to
deal with repositories that were deleted in other ways (eg. rm -rf).
- share the list of refs in a similar way (noticing that you probably
have different refs in multiple repos that are named
"refs/heads/master" of course) so that fetches will be efficient.
- extra improvement to submodule behaviour: hardlink packs from the
submodule into the supermodule's objects/pack directory (or use a
different directory like .git/submodules/pack to keep things
separate). Also, submodules should use the superproject's pack
directory as an alternate, in case (as often happens for me) the
supermodule already contains a bunch of objects from the submodule,
because the modules were split at some point.
I believe this would be quite easy to implement and would give an
immediate efficiency improvement. The ~/.gitcache feature could be
enabled/disabled by a config option. Is there any reason not to do
it?
Thanks,
Avery
P.S. I've been testing git's behaviour with lots of very large packs -
I'm currently using about 58 packs of about 1 GB each - as part of my
'bup' git-based backup tool (http://apenwarr.ca/log/?m=201001#04).
Repacking and fsck are obviously horrendously slow with that much
data, but bup avoids those operations as much as possible, and a
~/.gitcache wouldn't need to worry about them either (since each repo
is still responsible for repacking its own packs). Overall
performance for other git operations seems to be fine, though. And
searching the cache as a last restore can be optimized by always
searching packs in MRU order, in case git doesn't already do this.
^ permalink raw reply
* Re: [PATCH 1/5] MSVC: Windows-native implementation for subset of Pthreads API
From: Johannes Sixt @ 2010-01-08 20:40 UTC (permalink / raw)
To: kusmabite; +Cc: Dmitry Potapov, msysgit, git, Andrzej K. Haczewski
In-Reply-To: <40aa078e1001080258n67e0711sf4733a99d512bf1@mail.gmail.com>
On Freitag, 8. Januar 2010, Erik Faye-Lund wrote:
> On Fri, Jan 8, 2010 at 4:32 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> > AFAIK, Win32 API assumes that reading LONG is always atomic, so
> > the critical section is not really necesary here, but you need
> > to declare 'waiters' as 'volatile':
>
> "Simple reads and writes to properly-aligned 32-bit variables are
> atomic operations."
> http://msdn.microsoft.com/en-us/library/ms684122(VS.85).aspx
>
> In other words: Yes, you are right.
Quite frankly, I do not want to stretch this statement to apply to the MinGW
compiler. The code in question is not performance critical anyway. I'd prefer
to leave it as is - it's undergone 2 months of testing already. Besides,
IMHO, it is much more readable the way it is written.
-- Hannes
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Sverre Rabbelier @ 2010-01-08 20:37 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <32541b131001081231x1b6ac8c1k30084e4abf8cc896@mail.gmail.com>
Heya,
On Fri, Jan 8, 2010 at 15:31, Avery Pennarun <apenwarr@gmail.com> wrote:
> Thanks, I didn't know about that one. But my general point is still:
> we seem to have two implementations when the functionality of one is
> actually a superset of the other. As far as I can see, anyway. So
> the obvious way to reduce the duplicated code is to simply eliminate
> the less-featureful implementation.
*cough* git sequencer *cough*
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: ssh username environment variable
From: Chris Packham @ 2010-01-08 20:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vskag9vz0.fsf@alter.siamese.dyndns.org>
On Fri, Jan 8, 2010 at 3:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> Chris Packham <judge.packham@gmail.com> wrote:
>>> Just wondering if there is an environment variable I can use to tell
>>> git or ssh what user name to use for the ssh transport?
>>
>> No. But you can hack around it:
>>
>> cat >$HOME/bin/git-ssh
>> #!/bin/sh
>> ssh -l $GIT_SSH_USER "$@"
>> ^D
>>
>> GIT_SSH=$HOME/bin/git-ssh GIT_SSH_USER=myname git clone ...
>
> I thought the standard answer was "use $HOME/.ssh/config", to set User
> by keying on the remote hostname to which you are going.
>
Yeah thats what I've done after reading a few more man pages.
^ permalink raw reply
* Re: ssh username environment variable
From: Junio C Hamano @ 2010-01-08 20:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Chris Packham, git
In-Reply-To: <20100108202958.GL32155@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Chris Packham <judge.packham@gmail.com> wrote:
>> Just wondering if there is an environment variable I can use to tell
>> git or ssh what user name to use for the ssh transport?
>
> No. But you can hack around it:
>
> cat >$HOME/bin/git-ssh
> #!/bin/sh
> ssh -l $GIT_SSH_USER "$@"
> ^D
>
> GIT_SSH=$HOME/bin/git-ssh GIT_SSH_USER=myname git clone ...
I thought the standard answer was "use $HOME/.ssh/config", to set User
by keying on the remote hostname to which you are going.
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Avery Pennarun @ 2010-01-08 20:31 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <fabb9a1e1001081222q7122872bu72cea4e393f272ac@mail.gmail.com>
On Fri, Jan 8, 2010 at 3:22 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Fri, Jan 8, 2010 at 15:16, Avery Pennarun <apenwarr@gmail.com> wrote:
>> This would resolve any other inconsistencies between the two as well,
>> notably that non-interactive rebase sometimes refuses to do the rebase
>> I requested because "Current branch master is up to date," while
>> interactive rebase is willing to do it. (Personally I prefer the
>> latter behaviour, since I don't like tools that think they're smarter
>> than me :))
>
> I taught rebase the -f|--force-rebase flag a little while back, you
> could use that :).
Thanks, I didn't know about that one. But my general point is still:
we seem to have two implementations when the functionality of one is
actually a superset of the other. As far as I can see, anyway. So
the obvious way to reduce the duplicated code is to simply eliminate
the less-featureful implementation.
Avery
^ permalink raw reply
* Re: ssh username environment variable
From: Shawn O. Pearce @ 2010-01-08 20:29 UTC (permalink / raw)
To: Chris Packham; +Cc: git
In-Reply-To: <a038bef51001081224l33164526y51e5ca064b82b73a@mail.gmail.com>
Chris Packham <judge.packham@gmail.com> wrote:
> Just wondering if there is an environment variable I can use to tell
> git or ssh what user name to use for the ssh transport?
No. But you can hack around it:
cat >$HOME/bin/git-ssh
#!/bin/sh
ssh -l $GIT_SSH_USER "$@"
^D
GIT_SSH=$HOME/bin/git-ssh GIT_SSH_USER=myname git clone ...
--
Shawn.
^ permalink raw reply
* ssh username environment variable
From: Chris Packham @ 2010-01-08 20:24 UTC (permalink / raw)
To: git
Hi List,
Just wondering if there is an environment variable I can use to tell
git or ssh what user name to use for the ssh transport?
I would normally use
git clone ssh://myname@example.com/repo.git
but I'm cloning to a relatively public network drive (corporate
overlords don't want git no mater what I say) so I want to do
something like
GIT_SSH_USER=myname git clone ssh://example.com/repo.git
So that my user name doesn't show in the resulting remote.origin.url
I know I can probably just remove my user name from the config after
the the fact but I have to do this for a few repos so I thought I'd
ask if there was a magic environment variable I could set.
Thanks.
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Sverre Rabbelier @ 2010-01-08 20:22 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <32541b131001081216p27d7e29bu269755db895128@mail.gmail.com>
Heya,
On Fri, Jan 8, 2010 at 15:16, Avery Pennarun <apenwarr@gmail.com> wrote:
> This would resolve any other inconsistencies between the two as well,
> notably that non-interactive rebase sometimes refuses to do the rebase
> I requested because "Current branch master is up to date," while
> interactive rebase is willing to do it. (Personally I prefer the
> latter behaviour, since I don't like tools that think they're smarter
> than me :))
I taught rebase the -f|--force-rebase flag a little while back, you
could use that :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Avery Pennarun @ 2010-01-08 20:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <7vtyux3bx1.fsf@alter.siamese.dyndns.org>
2010/1/7 Junio C Hamano <gitster@pobox.com>:
> I am a bit unhappy about the duplication. The text of this function is
> different from the one in "rebase" proper, but they implement essentially
> the same logic. I was tempted to suggest having a common helper function,
> but as Dscho mentioned "rebase -i" implementation does not share much with
> "rebase" (even though it shares the external command line interface from
> the end user's point of view), and I don't see a readily available place
> (other than in git-sh-setup) to do so.
Is there a reason that non-interactive rebase can't just be
implemented as "git rebase -i" but without actually launching an
editor to edit the commit list?
This would resolve any other inconsistencies between the two as well,
notably that non-interactive rebase sometimes refuses to do the rebase
I requested because "Current branch master is up to date," while
interactive rebase is willing to do it. (Personally I prefer the
latter behaviour, since I don't like tools that think they're smarter
than me :))
Avery
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 19:58 UTC (permalink / raw)
To: Jeff King, Linus Torvalds; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7v8wc8jw3k.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nah, I should have checked the code.
>
> The implementation of ls-files does cd up and uses pathspec, so the intent
> is to apply higher level gitignore.
>
> It however feeds paths from the already ignored directories, which _is_
> the real bug.
> ...
> I think a proper fix should be in dir.c::read_directory() where it calls
> read_directory_recursive() without first checking if the directory itself
> should be ignored. read_directory_recursive() itself has a logic to see
> if the dirent it found is worth recursing into and a similar logic should
> be in the toplevel caller.
Actually doing less in fill_directory() turned out to be a simpler
solution.
builtin_add() cares about the return value from fill_directory() and
performs prune_directory() optimization magic, and we may want to change
it not to do so as well, but I didn't want to worry about too many things
at once, so this version still runs the "common_prefix()" that forgets to
take .gitignore at higher levels (or a $GIT_DIR/info/exclude entry that
ignores the common prefix directory of given pathspecs) into account.
Another possibility is to fix common_prefix() and make it walk the path it
returns one level at a time from the top, making sure they are not
ignored, and that would probably be a better fix, but at least this patch
will give you a starting point and tests to check the result against.
diff --git a/dir.c b/dir.c
index d0999ba..56d3f60 100644
--- a/dir.c
+++ b/dir.c
@@ -53,7 +53,6 @@ static int common_prefix(const char **pathspec)
int fill_directory(struct dir_struct *dir, const char **pathspec)
{
- const char *path;
int len;
/*
@@ -61,13 +60,8 @@ int fill_directory(struct dir_struct *dir, const char **pathspec)
* use that to optimize the directory walk
*/
len = common_prefix(pathspec);
- path = "";
-
- if (len)
- path = xmemdupz(*pathspec, len);
-
/* Read the directory and prune it */
- read_directory(dir, path, len, pathspec);
+ read_directory(dir, "", 0, pathspec);
return len;
}
diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
index c65bca8..17d1764 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -153,4 +153,42 @@ test_expect_success 'negated exclude matches can override previous ones' '
grep "^a.1" output
'
+test_expect_success 'subdirectory ignore (setup)' '
+ mkdir -p top/l1/l2 &&
+ (
+ cd top &&
+ git init &&
+ echo /.gitignore >.gitignore &&
+ echo l1 >>.gitignore &&
+ echo l2 >l1/.gitignore
+ )
+'
+
+test_expect_success 'subdirectory ignore (toplevel)' '
+ (
+ cd top &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'subdirectory ignore (l1/l2)' '
+ (
+ cd top/l1/l2 &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'subdirectory ignore (l1)' '
+ (
+ cd top/l1 &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
test_done
^ permalink raw reply related
* Re: git-log - hide parent (was: merging two equivalent branches)
From: Avery Pennarun @ 2010-01-08 19:50 UTC (permalink / raw)
To: David Reitter; +Cc: git, Christian MICHON
In-Reply-To: <DF05F91F-CBFD-458A-A99F-79E98ACA5146@gmail.com>
On Thu, Jan 7, 2010 at 4:16 PM, David Reitter <david.reitter@gmail.com> wrote:
> I'm still unsure how, after the filter-branch, I would have some ancestor from the
> B series so that future pulls from the remote work, while having an ancestor from
> A, to make sure I can continue merging into C. If history is rewritten, I'll get new
> revisions and lose ancestors.
> I'm beginning to thing that the cutting and pasting I'd like is conceptually impossible.
Hmm, this is pretty nasty. Essentially, you want your repo to include
both sets of commits (so that it doesn't try to re-merge in the other
commits later), but you don't want to *see* them in git log.
Basically, you want git log to lie to you :)
Luckily, it already has this ability: it's called history simplification :)
Try this in your merged repo:
git log .
(note the '.').
Without the dot, git log doesn't simplify any history, and you get
every change. With the dot, it shows only commits that had a tangible
effect on the file in question (in this case, the top directory, which
includes *everything*). Thus, a "git merge -s ours" gets eliminated.
Beware that it might eliminate other equally non-impactful commits, however.
The same trick also works with gitk.
Have fun,
Avery
^ permalink raw reply
* Re: Difference between pull --rebase and fetch+rebase
From: martinvz @ 2010-01-08 19:41 UTC (permalink / raw)
To: git
In-Reply-To: <adf1fd3d1001080305k138a2670k17a126cc0b8430b8@mail.gmail.com>
Santi Béjar-2 wrote:
>
> Yes, it is. The code expects that you always branch your topic
> branches from the upstream branch, so all the possible fork points are
> in the reflog. Your flow was to create the topic from a local commit
> and then push that commit.
>
Thanks, Santi! After thinking for a while about what you said, I think I
understand. That could definitely be what I did, although I can't remember
for sure.
Would it make sense to teach "git rebase" the same tricks as "git pull
--rebase"?
Santi Béjar-2 wrote:
>
> By the way, when Git tries to apply these two commits it should detect
> that they are already applied so it should do nothing, isn't it?
>
Almost - it fails, but the merge tool resolves it automatically.
Martin
--
View this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4274470.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Document git-blame triple -C option
From: Ramkumar Ramachandra @ 2010-01-08 18:58 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B47510E.7040802@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
> Above you see why it is difficult to comment on attached patches.
> They're not included!
I'm sorry, but I'm behind a HTTP proxy, and GMail mangles up patches.
I'm left with no choice but to attach the patches.
> You re-wrapped the existing documentation. Please don't do that, because
> it makes it difficult to spot what you really changed.
Okay. Corrected.
> It seems you added one sentence. Please don't use "thrice" for "three
> times", that is very old English and sounds funny.
Okay. I've also modified the second line (what happens when the option
is given twice) for clarity.
[-- Attachment #2: 0001-Document-git-blame-triple-C-option.patch --]
[-- Type: text/x-patch, Size: 1892 bytes --]
From 371705f64576ff7b8dc82bea19c714ce320097b9 Mon Sep 17 00:00:00 2001
From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Sat, 9 Jan 2010 00:18:07 +0530
Subject: [PATCH v2] Document git-blame triple -C option
git-blame -CCC is explained in builin-blame.c line 2171, but is
unexplained in the documentation. This patch fixes that.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/blame-options.txt | 6 ++++--
Documentation/git-blame.txt | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 1625ffc..4833cac 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -98,8 +98,10 @@ commit.
files that were modified in the same commit. This is
useful when you reorganize your program and move code
around across files. When this option is given twice,
- the command additionally looks for copies from all other
- files in the parent for the commit that creates the file.
+ the command additionally looks for copies from other
+ files in the commit that creates the file. When this
+ option is given three times, the command additionally
+ looks for copies from other files in any commit.
+
<num> is optional but it is the lower bound on the number of
alphanumeric characters that git must detect as moving
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 8c7b7b0..b786471 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
- [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
+ [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
[<rev> | --contents <file> | --reverse <rev>] [--] <file>
DESCRIPTION
--
1.6.5
^ permalink raw reply related
* Re: Linking multiple Git repositories for version tracking
From: Avery Pennarun @ 2010-01-08 18:34 UTC (permalink / raw)
To: James Beck; +Cc: git@vger.kernel.org
In-Reply-To: <op.u574cwxqn3qeew@klee>
On Fri, Jan 8, 2010 at 12:03 PM, James Beck <james@jmbeck.com> wrote:
> I'm developing firmware that is composed of multiple projects. Each
> section of the firmware has it's own git repository (each section
> correlates to a physical processor). But the firmware as a whole is
> getting to the point where I have to remember which version of Firmware A
> is compatible with Firmware B. If I add a feature to B that requires some
> tweaks in A, I need to know that both A v3.04 and B v2.7 need to be used
> together.
>
> I'm starting to move into alpha with this code, so I really need to have a
> system that keeps track of compatible firmware versions. The best I can
> come up with is a plain text file (or Excel spreadsheet) that lists the
> overall firmware version, and the Git hash for each individual project.
> That way, if I want to load up a particular firmware version, I can
> checkout each hash for that version. Seems foolproof, but not terribly
> easy, and somewhat annoying.
>
> I know submodules might be used, but it's not super obvious how to make
> their paradigm work nicely here. (You check out a version you want, and
> then list all the submodule git hashes for that version? What happens if
> one hash needs updating? Do you branch it?) It seems more complicated than
> I'd like.
This seems like exactly what submodules were designed to do.
1. create a "superproject" for each physical product
2. use submodules to link to the right firmware versions for that product
3. when you make a new release of that physical product, update the
firmware links.
4. when someone wants to check out a particular version of the
product, they retrieve the product's repo and ask git submodule to
checkout the submodules.
Which part is not working for you?
Have fun,
Avery
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 18:21 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vskag1r5o.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> Well, yes, if you wanted to compare apples to apples. But actually, my
>> point in showing "status" at all was to note that Michael's statement
>> that they would be the same is wrong.
>>
>> But just looking at the ls-files output, do you not agree that there is
>> a bug?
>
> If I agreed, I wouldn't have suggested _you_ to cd up and use pathspec,
> but instead would have suggested to patch ls-files to make it do so for
> you.
Nah, I should have checked the code.
The implementation of ls-files does cd up and uses pathspec, so the intent
is to apply higher level gitignore.
It however feeds paths from the already ignored directories, which _is_
the real bug.
For example, if you have
.gitignore (ignores t/)
t/
t/junk
in your work tree, it will read .gitignore at the top level, and
eventually end up feeding "t/junk" to dir.c::excluded_1(), which does:
for (i = el->nr - 1; 0 <= i; i--) {
struct exclude *x = el->excludes[i];
const char *exclude = x->pattern;
int to_exclude = x->to_exclude;
if (x->flags & EXC_FLAG_MUSTBEDIR) {
if (*dtype == DT_UNKNOWN)
*dtype = get_dtype(NULL, pathname, pathlen);
if (*dtype != DT_DIR)
continue;
}
...
where *x has "'t/' that must be directory". but the path "t/junk" does
not match with "t/" and is not excluded by this rule; this part notices
"t/junk" is not a directory, and continues without giving the later part a
chance to intervene. Of course, the later part also is not prepared to do
a "leading path" match, as the function is not meant to be fed entries
from ignored "t/" directory in the first place.
I think a proper fix should be in dir.c::read_directory() where it calls
read_directory_recursive() without first checking if the directory itself
should be ignored. read_directory_recursive() itself has a logic to see
if the dirent it found is worth recursing into and a similar logic should
be in the toplevel caller.
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Jeff King @ 2010-01-08 17:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vaawosfg9.fsf@alter.siamese.dyndns.org>
On Fri, Jan 08, 2010 at 08:56:38AM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > You can see it as a feature that you can use to check what would happen
> > if you stopped ignoring the directory from the higher level. With a patch
> > to always cd-up and use pathspec, that will become impossible.
>
> I hate to say this, but I have a feeling that status might be what needs
> to be fixed instead. It isn't hard to imagine a use case where you don't
> want to be bothered by crufts in lower level directories when you are
> looking at the bigger picture (e.g. at the top of the hierarchy) but when
> you go to individual subdirectory you would want to see them.
For people who have status.relativepaths off, status is still a global
command. So I would hope that behavior would come out only when doing
"git status .", or at the very least be disabled if status.relativepaths
is set.
Personally, I think having ignored files show up as untracked based on
heuristics like cwd is just going to end up confusing people.
-Peff
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Jeff King @ 2010-01-08 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vskag1r5o.fsf@alter.siamese.dyndns.org>
On Fri, Jan 08, 2010 at 08:45:55AM -0800, Junio C Hamano wrote:
> > But just looking at the ls-files output, do you not agree that there is
> > a bug?
>
> If I agreed, I wouldn't have suggested _you_ to cd up and use pathspec,
> but instead would have suggested to patch ls-files to make it do so for
> you.
Ah, I missed the subtlety there.
> You can see it as a feature that you can use to check what would happen
> if you stopped ignoring the directory from the higher level. With a patch
> to always cd-up and use pathspec, that will become impossible.
>
> Maybe nobody needs such a feature (I don't), in which case we can declare
> it as a bug. But I wasn't ready to do so myself when I wrote the message
> you are responding to, and I still am not.
That feature seems somewhat insane to me. If I wanted to know how things
would look without gitignore, I would not have said --exclude-standard.
However, I was wrong before that it ignores .gitignore. It doesn't. If
you put "cruft" instead of "subdir" into gitignore in my previous
example, it is correctly ignored. So it is sort of a "half-use
gitignore", which you cannot accomplish any other way.
I still think it's a bit crazy to have as the default behavior. But at
least it's constrained to a plumbing command, which scripts can work
around to get what they want. With the current behavior, that means the
bash prompt code should be doing "git rev-parse --show-cdup --show-prefix"
and moving to the toplevel.
-Peff
^ permalink raw reply
* Linking multiple Git repositories for version tracking
From: James Beck @ 2010-01-08 17:03 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <op.u573txvdn3qeew@klee>
Hi,
I'm developing firmware that is composed of multiple projects. Each
section of the firmware has it's own git repository (each section
correlates to a physical processor). But the firmware as a whole is
getting to the point where I have to remember which version of Firmware A
is compatible with Firmware B. If I add a feature to B that requires some
tweaks in A, I need to know that both A v3.04 and B v2.7 need to be used
together.
I'm starting to move into alpha with this code, so I really need to have a
system that keeps track of compatible firmware versions. The best I can
come up with is a plain text file (or Excel spreadsheet) that lists the
overall firmware version, and the Git hash for each individual project.
That way, if I want to load up a particular firmware version, I can
checkout each hash for that version. Seems foolproof, but not terribly
easy, and somewhat annoying.
I know submodules might be used, but it's not super obvious how to make
their paradigm work nicely here. (You check out a version you want, and
then list all the submodule git hashes for that version? What happens if
one hash needs updating? Do you branch it?) It seems more complicated than
I'd like.
But this can't be a problem that only I have. What have you done to keep
track of software bundle versions?
Thanks!
James
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 16:56 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vskag1r5o.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> You can see it as a feature that you can use to check what would happen
> if you stopped ignoring the directory from the higher level. With a patch
> to always cd-up and use pathspec, that will become impossible.
I hate to say this, but I have a feeling that status might be what needs
to be fixed instead. It isn't hard to imagine a use case where you don't
want to be bothered by crufts in lower level directories when you are
looking at the bigger picture (e.g. at the top of the hierarchy) but when
you go to individual subdirectory you would want to see them.
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 16:45 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <20100108164132.GA6171@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Well, yes, if you wanted to compare apples to apples. But actually, my
> point in showing "status" at all was to note that Michael's statement
> that they would be the same is wrong.
>
> But just looking at the ls-files output, do you not agree that there is
> a bug?
If I agreed, I wouldn't have suggested _you_ to cd up and use pathspec,
but instead would have suggested to patch ls-files to make it do so for
you.
You can see it as a feature that you can use to check what would happen
if you stopped ignoring the directory from the higher level. With a patch
to always cd-up and use pathspec, that will become impossible.
Maybe nobody needs such a feature (I don't), in which case we can declare
it as a bug. But I wasn't ready to do so myself when I wrote the message
you are responding to, and I still am not.
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Jeff King @ 2010-01-08 16:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vr5q05z74.fsf@alter.siamese.dyndns.org>
On Fri, Jan 08, 2010 at 08:38:39AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Try this:
> >
> > git init
> > touch base-cruft
> > mkdir subdir
> > touch subdir/cruft
> > echo subdir >.gitignore
> > git status ;# shows gitignore and base-cruft
> > git ls-files -o --exclude-standard ;# ditto
> > cd subdir
> > git status . ;# shows nothing, since everything in subdir is ignored
> > git ls-files -o --exclude-standard ;# BUG: shows cruft
> >
> > Yes, ls-files operates in the subdirectory, which means it should not
> > show cruft from the root (and it does not). But it should respect
> > .gitignore directives going all the way back to the root, and it
> > doesn't.
>
> Shouldn't the ls-files be run from the root with subdir/ as pathspec, if
> you wanted to do apples-to-apples comparison between it and status?
Well, yes, if you wanted to compare apples to apples. But actually, my
point in showing "status" at all was to note that Michael's statement
that they would be the same is wrong.
But just looking at the ls-files output, do you not agree that there is
a bug? Respecting gitignore means respecting _all_ gitignore files in
the repository, not just the subset that you happen to be in.
-Peff
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 16:38 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <20100108162404.GA5799@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Try this:
>
> git init
> touch base-cruft
> mkdir subdir
> touch subdir/cruft
> echo subdir >.gitignore
> git status ;# shows gitignore and base-cruft
> git ls-files -o --exclude-standard ;# ditto
> cd subdir
> git status . ;# shows nothing, since everything in subdir is ignored
> git ls-files -o --exclude-standard ;# BUG: shows cruft
>
> Yes, ls-files operates in the subdirectory, which means it should not
> show cruft from the root (and it does not). But it should respect
> .gitignore directives going all the way back to the root, and it
> doesn't.
Shouldn't the ls-files be run from the root with subdir/ as pathspec, if
you wanted to do apples-to-apples comparison between it and status?
^ 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