* Re: [PATCH 2/5] First step, making setup (somewhat) reentrant
From: Johannes Schindelin @ 2008-01-07 11:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Thaeter, git
In-Reply-To: <7v4pdq0z30.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 7 Jan 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Which brings me to a more fundamental question: what do you need
> > reentrant setup_directory() for? If it is just to allow multiple
> > calls to that function for the _same_ repository, I say clean up your
> > code.
>
> IIRC, he is writing a set-of-repositories browser.
>
> But I think the right approach of cleaning up is to design a
> layer of containers like we did for "the_index" libification
Yes, I concur. That was a nice abstraction without impacting existing code
too much.
Ciao,
Dscho
^ permalink raw reply
* Re: [STG PATCH] refresh: add a --index option which takes the contents of the index as the new commit
From: Karl Hasselström @ 2008-01-07 10:56 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: Git Mailing List, Catalin Marinas
In-Reply-To: <200801022039.27611.kumbayo84@arcor.de>
On 2008-01-02 20:39:27 +0100, Peter Oberndorfer wrote:
> On Sonntag 30 Dezember 2007, Peter Oberndorfer wrote:
>
> > Do you think this would be a useful/good idea? Or do we want a
> > separate command for removing files from a patch anyway?
>
> The question is still open if this is useful for somebody else.
I think it's a useful addition. Thanks!
> diff --git a/stgit/stack.py b/stgit/stack.py
> index 4203931..7d14261 100644
> --- a/stgit/stack.py
> +++ b/stgit/stack.py
> @@ -668,6 +668,7 @@ class Series(PatchSet):
> config.remove_section('branch.%s.stgit' % self.get_name())
>
> def refresh_patch(self, files = None, message = None, edit = False,
> + use_index = False,
> empty = False,
> show_patch = False,
> cache_update = True,
> @@ -717,6 +718,11 @@ class Series(PatchSet):
> else:
> tree_id = None
>
> + if use_index:
> + tree_id = None
> + files = None
> + cache_update = False
> +
> commit_id = git.commit(files = files,
> message = descr, parents = [bottom],
> cache_update = cache_update,
So the use_index parameter to refresh_patch is actually not necessary?
In that case I'd rather you didn't add it, since the functions in
stgit/stack.py have quite enough parameters already.
> diff --git a/t/t2700-refresh.sh b/t/t2700-refresh.sh
> index 2e7901c..9eae85d 100755
> --- a/t/t2700-refresh.sh
> +++ b/t/t2700-refresh.sh
Bonus points for adding a test case!
I still haven't rebased my patch stack since Catalin accepted most of
it just before Christmas. Once I've gotten around to that, I'll take
your patch -- hopefully by then updated to not add the exra argument
to refresh_patch(). :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Repository specific git commands
From: Ciprian Dorin Craciun @ 2008-01-07 12:15 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
Hello all!
I have a question / proposal: I see on the mailing list a lot of
situations when some commands (or group of commands) are very often
used and the users demand (or would like to have) a special "git xxx"
command for them. But adding such a command -- in almost all cases --
is not worth the effort or increases the number of available commands
(thus confusing even more the users).
Thus the users are left with only two possibilities:
-- either define an alias -- but usually it is very restrictive in
terms of what the alias can do;
-- create a custom git command "git-xxx" and place it in the
executable path -- but this requires root access.
(-- or write a custom script but this can not be invoked as "git xxx")
=> Thus neither option is very useful.
So my proposal is to let the users create a special folder inside
the .git directory, for example ".git/bin" where they can place custom
built git files like "git-xxx", and when they issue "git xxx" this
folder is searched first, and if the command is found it will be
executed as any other "git-xxx".
For this I attach a very simple patch that implements it. (It
modifies the execv_git_cmd function by adding a new path in the paths
array.)
Comments? Opinions? Other solutions that I am not aware of?
(Please note that I am a git user for only a couple of months, and
this is the first time I look over git source code...)
Thanks,
Ciprian Craciun.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch.diff --]
[-- Type: text/x-diff; name=patch.diff, Size: 779 bytes --]
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..9082711 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -30,11 +30,32 @@ const char *git_exec_path(void)
}
+static const char *git_repo_exec_path(void)
+{
+ static char path_buffer[PATH_MAX + 1];
+ static char *path = NULL;
+
+ if (!path) {
+ path = path_buffer;
+ path[0] = '\0';
+ if (get_git_dir()) {
+ strncat(path, get_git_dir(), PATH_MAX);
+ strncat(path, "/", PATH_MAX);
+ strncat(path, "bin", PATH_MAX);
+ }
+ }
+
+ return path;
+}
+
+
int execv_git_cmd(const char **argv)
{
char git_command[PATH_MAX + 1];
int i;
- const char *paths[] = { current_exec_path,
+ const char *paths[] = {
+ git_repo_exec_path(),
+ current_exec_path,
getenv(EXEC_PATH_ENVIRONMENT),
builtin_exec_path };
^ permalink raw reply related
* Re: [STG PATCH] refresh: add a --index option which takes the contents of the index as the new commit
From: Karl Hasselström @ 2008-01-07 10:59 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: Git Mailing List, Catalin Marinas
In-Reply-To: <20080107105612.GA20981@diana.vm.bytemark.co.uk>
On 2008-01-07 11:56:12 +0100, Karl Hasselström wrote:
> hopefully by then updated to not add the exra argument to
> refresh_patch(). :-)
And with a sign-off, too, please.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-07 12:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Karlsson, Git Mailing List
In-Reply-To: <7vzlviymxw.fsf@gitster.siamese.dyndns.org>
On Jan 7, 2008, at 11:00 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Per default, CRLF conversion is disabled in msysgit.
>
> That's interesting, as core.autocrlf was invented _specifically_
> for use on Windows.
My take on this is that is was invented for cross-platform projects.
But if you have a Windows-only project it does not make sense to
convert line endings. Only if you plan to work on multiple
platforms, line ending conversion makes sense. The most
conservative choice is to leave content unmodified. This is true
for Windows, as it is for Unix. Therefore, msysgit does not
modify your content unless requested otherwise.
Steffen
^ permalink raw reply
* Re: Repository specific git commands
From: Johannes Schindelin @ 2008-01-07 12:55 UTC (permalink / raw)
To: Ciprian Dorin Craciun; +Cc: git
In-Reply-To: <8e04b5820801070415j5166c2eco53760cffe1ab1efb@mail.gmail.com>
Hi,
On Mon, 7 Jan 2008, Ciprian Dorin Craciun wrote:
> -- either define an alias -- but usually it is very restrictive in
> terms of what the alias can do;
You probably missed the possibility of executing a shell command (or
commands) viathe "!" prefix.
See also
http://git.or.cz/gitwiki/Aliases/
Hth,
Dscho
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-07 12:58 UTC (permalink / raw)
To: Peter Klavins; +Cc: git
In-Reply-To: <flsu0r$m9p$1@ger.gmane.org>
On Jan 7, 2008, at 11:13 AM, Peter Klavins wrote:
> I use an alternate workaround that clones the repository, removes
> the checked out files, sets autocrlf, then checks out the files again:
>
> $ git clone git://git.debian.org/git/turqstat/turqstat.git
> $ cd turqstat
> $ git config --add core.autocrlf true
> $ rm -rf * .gitignore
> $ git reset --hard
>
> The result should now be the same as using Steffen's system.
Yes, this should yield the same.
> However, there is still an unresolved problem with git's way of
> treating cr/lf as an attribute only of the checkout and not the
> repository itself:
>
> $ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: visualc/.gitignore
> # modified: visualc/turqstat.sln
> # modified: visualc/turqstat.vcproj
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> So, checking out the repository with cr/lf true has now caused
> misalignment of files that were originally checked in with existing
> cr/lf's in place. Visual Studio in fact happily works with files
> that only have lf endings, _except_ *.sln and *.vcproj files, which
> it much prefers to have with cr/lf endings.
You could try .gitattributes to exclude files from crlf
conversion. But I'd not recommend this, because the mechanism
has some deficiencies, as discussed in
http://thread.gmane.org/gmane.comp.version-control.git/61888
> The _real_ solution to this problem for the moment is _not_ to mix
> files with both lf and cr/lf endings in the repository.
This is the way to go.
> So, the original author of the repository should _also_ have used
> core.autocrlf true, thus causing the *sln and *vcproj to have their
> cr's stripped on checkin, but replaced on checkout when checking
> out with autocrlf true.
For cross-platform projects, I recommend to explicitly configure
autocrlf on Windows and Unix. On Windows set
git config core.autocrlf true # on Windows
and on Unix set
git config core.autocrlf input # on Unix
This ensures that the repository only contains LF. Even if someone
emails source code from Windows to Unix and commits it there.
Steffen
^ permalink raw reply
* Re: Repository specific git commands
From: Ciprian Dorin Craciun @ 2008-01-07 13:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0801071352470.14355@wbgn129.biozentrum.uni-wuerzburg.de>
On 1/7/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 7 Jan 2008, Ciprian Dorin Craciun wrote:
>
> > -- either define an alias -- but usually it is very restrictive in
> > terms of what the alias can do;
>
> You probably missed the possibility of executing a shell command (or
> commands) viathe "!" prefix.
>
> See also
>
> http://git.or.cz/gitwiki/Aliases/
>
> Hth,
> Dscho
I knew about the "!" prefix but this allows me to write only a
one-line script... But in the case I want more complex scripts? (Just
look at how hard it is to read the "Getting the diff of only one
function" example...) (Yes I could create a script, place it in a
special folder and add an alias to it -- remembering to put the right
path... But it is not as simple as adding it to the bin directory.)
Ciprian.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Karlsson @ 2008-01-07 13:50 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, Peter Klavins
In-Reply-To: <flsu0r$m9p$1@ger.gmane.org>
Steffen Prohaska:
> Per default, CRLF conversion is disabled in msysgit. Git should
> not convert a single file. Does it really convert some?
I didn't verify, but it was only some files that had LFs, perhaps the
files that I added while on the Windows machine had CRLFs. That's bad.
Peter Klavins:
> Visual Studio in fact happily works with files that only have lf
> endings, _except_ *.sln and *.vcproj files, which it much prefers to
> have with cr/lf endings.
The project files were added to the repository on the Windows box
(obviously), so those are correct.
So apparently my repository is a bit broken at the moment with LF on
some files and CRLF on some. That's bad. I just assumed everything
worked, it used to "just work" for CVS (except for when you actually
tried to add binary files, of course).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Klavins @ 2008-01-07 14:14 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0801071447320.1864@ds9.cixit.se>
> So apparently my repository is a bit broken at the moment with LF on
> some files and CRLF on some. That's bad. I just assumed everything
> worked, it used to "just work" for CVS (except for when you actually
> tried to add binary files, of course).
LOL. Exactly. That's my only gripe with git, there's still some way to go
before it's as usable as CVS in this regard, but of course in every other
feature it's way superior.
If you follow the steps I listed, you will have new .sln and .vcproj files
that you can commit over the top of the ones already there, and everything
will be fixed! I checked out your project and it built fine.
------------------------------------------------------------------------
Peter Klavins
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-07 16:05 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git, Peter Klavins
In-Reply-To: <Pine.LNX.4.64.0801071447320.1864@ds9.cixit.se>
On Jan 7, 2008, at 2:50 PM, Peter Karlsson wrote:
> Steffen Prohaska:
>
>> Per default, CRLF conversion is disabled in msysgit. Git should
>> not convert a single file. Does it really convert some?
>
> I didn't verify, but it was only some files that had LFs, perhaps the
> files that I added while on the Windows machine had CRLFs. That's bad.
This is a typical problem. Once CRLFs are in your repository
autocrlf can't "just work" anymore. You need to commit a fixed
version of the files.
> Peter Klavins:
>
>> Visual Studio in fact happily works with files that only have lf
>> endings, _except_ *.sln and *.vcproj files, which it much prefers to
>> have with cr/lf endings.
>
> The project files were added to the repository on the Windows box
> (obviously), so those are correct.
>
>
> So apparently my repository is a bit broken at the moment with LF on
> some files and CRLF on some. That's bad. I just assumed everything
> worked, it used to "just work" for CVS (except for when you actually
> tried to add binary files, of course).
"Just works" has a different meaning for git than it has for CVS.
For git, it means that once you _told_ git how to convert line
endings (that is you have correctly configured autocrlf), git
will automatically detect text files and convert them, but leave
binary files untouched. It "just works" in the sense that you do
not need to explicitly tell git about every single binary files
(no cvs -kb needed). Git will auto-detect the file type.
But if you does tell git to convert line endings it "just works"
as if every file was binary. Per default, git does not modify
your content. And for some people, "just works" means exactly
this: leave my content as is.
So it really depends on the context and therefore some
configuration is inevitable. git requires you to configure
autocrlf. cvs requires you to set -kb.
You may, though, set "core.autocrlf true" globally for your
account. After you did this, git should "just work" for you; if
"just works" means convert CRLF in _all_ text files in _every_
repository.
Steffen
^ permalink raw reply
* [PATCH] Change git-gc documentation to reflect gc.packrefs implementation.
From: Florian La Roche @ 2008-01-07 16:21 UTC (permalink / raw)
To: git
Change git-gc documentation to reflect gc.packrefs implementation.
---
Documentation/git-gc.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index c4354bb..4b2dfef 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -90,9 +90,9 @@ how long records of conflicted merge you have not resolved are
kept. This defaults to 15 days.
The optional configuration variable 'gc.packrefs' determines if
-`git gc` runs `git-pack-refs`. Without the configuration, `git-pack-refs`
-is not run in bare repositories by default, to allow older dumb-transport
-clients fetch from the repository, but this will change in the future.
+`git gc` runs `git-pack-refs`. This can be set to "nobare" to enable
+it within all non-bare repos or it can be set to a boolean value.
+This defaults to true.
The optional configuration variable 'gc.aggressiveWindow' controls how
much time is spent optimizing the delta compression of the objects in
--
1.5.3.7
^ permalink raw reply related
* gitk dev branch: F5 gives error after commit
From: Johannes Sixt @ 2008-01-07 16:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
I use the dev branch of gitk (on Windows), commit 476ca63 (gitk: Index
[fnvr]highlights by id rather than row).
1. Start it with:
gitk --all -300
2. Make a commit.
3. Hit F5. Here I see the error message:
Error reading commits:
fatal: bad revision '^-300'
At this time the label of the current branch is already gone from the
commit list. There are no other changes made in the display.
Hitting F5 again does nothing. I have to create a new view to get an
updated display.
Any help is appreciated. Thanks,
-- Hannes
^ permalink raw reply
* [PATCH] git-stash: add new 'drop' subcommand
From: Brandon Casey @ 2008-01-07 17:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
This allows a single stash entry to be deleted. It takes an
optional argument which is a stash reflog entry. If no
arguments are supplied, it drops the most recent stash entry.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
This implements the suggested changes on top of latest next.
We can leave the discussion of naming and any other issues
until after 1.5.4 so not to cause a distraction unless
people feel otherwise.
-brandon
Documentation/git-stash.txt | 7 ++++++-
git-stash.sh | 25 ++++++++++++++++++++++++-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 9889806..7afc8d3 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,7 +8,7 @@ git-stash - Stash the changes in a dirty working directory away
SYNOPSIS
--------
[verse]
-'git-stash' (list | show [<stash>] | apply [<stash>] | clear)
+'git-stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>])
'git-stash' [save] [message...]
DESCRIPTION
@@ -81,6 +81,11 @@ clear::
Remove all the stashed states. Note that those states will then
be subject to pruning, and may be difficult or impossible to recover.
+drop [<stash>]::
+
+ Remove a single stashed state from the stash list. When no `<stash>`
+ is given, it removes the latest one. i.e. `stash@\{0}`
+
DISCUSSION
----------
diff --git a/git-stash.sh b/git-stash.sh
index b00f888..d6d77fa 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -1,7 +1,7 @@
#!/bin/sh
# Copyright (c) 2007, Nanako Shiraishi
-USAGE='[ | save | list | show | apply | clear | create ]'
+USAGE='[ | save | list | show | apply | clear | drop | create ]'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
@@ -196,6 +196,25 @@ apply_stash () {
fi
}
+drop_stash () {
+ have_stash || die 'No stash entries to drop'
+
+ test $# = 0 && set -- "$ref_stash@{0}"
+
+ # Verify supplied argument looks like a stash entry
+ s=$(git rev-parse --revs-only --no-flags "$@") &&
+ git rev-parse --verify "$s:" > /dev/null 2>&1 &&
+ git rev-parse --verify "$s^1:" > /dev/null 2>&1 &&
+ git rev-parse --verify "$s^2:" > /dev/null 2>&1 ||
+ die "$*: not a valid stashed state"
+
+ git reflog delete "$@" && echo "Dropped $* ($s)" ||
+ die "$*: Could not drop stash entry"
+
+ # clear_stash if we just dropped the last stash entry
+ git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
+}
+
# Main command set
case "$1" in
list)
@@ -230,6 +249,10 @@ create)
fi
create_stash "$*" && echo "$w_commit"
;;
+drop)
+ shift
+ drop_stash "$@"
+ ;;
*)
if test $# -eq 0
then
--
1.5.3.6
^ permalink raw reply related
* Re: gitk dev branch: F5 gives error after commit
From: Marco Costalba @ 2008-01-07 18:19 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <478258B6.20006@viscovery.net>
On Jan 7, 2008 5:52 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> I use the dev branch of gitk (on Windows), commit 476ca63 (gitk: Index
> [fnvr]highlights by id rather than row).
>
> 1. Start it with:
>
> gitk --all -300
>
> 2. Make a commit.
> 3. Hit F5. Here I see the error message:
>
> Error reading commits:
> fatal: bad revision '^-300'
>
Windows command line does not handles the ^ symbol.
Try open a console with cmd.exe and type
git log HEAD^
Marco
^ permalink raw reply
* Re: rm and mv commands: should I use them?
From: Robin Rosenberg @ 2008-01-07 18:37 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Linus Torvalds, Jon Hancock, git
In-Reply-To: <20080107030642.GA18194@coredump.intra.peff.net>
måndagen den 7 januari 2008 skrev Jeff King:
> On Sun, Jan 06, 2008 at 06:05:16PM -0800, Junio C Hamano wrote:
...
> > "git mv" should not have staged the change. It should have
> > moved the index entry from Makefile to makefile and moved the
> > work tree files.
>
> I thought there was some discussion about this a few months ago,
> concerning what exactly it should do, and that was how we arrived at the
> current behavior. However, I can't seem to find it now. Maybe I dreamed
> it.
I had the same dream.
-- robin
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Robin Rosenberg @ 2008-01-07 18:47 UTC (permalink / raw)
To: Jeff King; +Cc: Steffen Prohaska, Peter Karlsson, Git Mailing List
In-Reply-To: <20080107101256.GA25047@coredump.intra.peff.net>
måndagen den 7 januari 2008 skrev Jeff King:
> On Mon, Jan 07, 2008 at 10:57:52AM +0100, Steffen Prohaska wrote:
>
> I don't know if there are other options that might impact how clone
> works, but something like the patch below might make sense. It would
> allow:
>
> git clone -c core.autocrlf=true ...
You can also set the option globally. Maybe something for the installer or a first time wizard.
But I do think git should have this option set right from the beginning. It could print out somethig
to notify the user that (and which) some options are not set the same as on unix.
-- robin
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-07 19:16 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Jeff King, Steffen Prohaska, Peter Karlsson, Git Mailing List
In-Reply-To: <200801071947.28586.robin.rosenberg.lists@dewire.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 676 bytes --]
Hi,
On Mon, 7 Jan 2008, Robin Rosenberg wrote:
> måndagen den 7 januari 2008 skrev Jeff King:
> > On Mon, Jan 07, 2008 at 10:57:52AM +0100, Steffen Prohaska wrote:
> >
> > I don't know if there are other options that might impact how clone
> > works, but something like the patch below might make sense. It would
> > allow:
> >
> > git clone -c core.autocrlf=true ...
>
> You can also set the option globally. Maybe something for the installer
> or a first time wizard.
We thought about that, too.
> But I do think git should have this option set right from the beginning.
Problem. There is not a single "right". It really depends on the
project.
Ciao,
Dscho
^ permalink raw reply
* Re: RFC/RFH submodule handling in big setups
From: Junio C Hamano @ 2008-01-07 19:46 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20080107102327.GA12427@pvv.org>
Finn Arne Gangstad <finnag@pvv.org> writes:
> We're trying to get git to work well with our vision of submodules,
> and have to figure out how to make submodule fetching and pushing work
> in a smooth way.
>
> This is our situation (simplified):
>
> [product1] [product2] ... (supermodules)
> / \ / \
> ... [foo] [os-abstraction-lib] [log-merger] ... (submodules)
>
>
> A developer does a modification to the os-abstraction-lib, and a
> modification to the log-merger that depends on the change in the
> os-abstraction-lib. He wants this into product2, and doesn't know or
> care about product1. He doesn't know whether his modification is
> acceptable or not, or whether his modification will go in before some
> other modification.
>
> He needs some way of pushing his modifications to a branch in the
> supermodule (e.g. "change-131345"), without interfering with anyone
> else. The problem is where to push the sub-modules, they need to be
> available for anyone who wants to get the "change-131345" branch of
> the product2, but the modifications shouldn't show up anywhere else
> (yet). Here are solutions we have thought of so far:
The phrase "without interfering with anyone else" feels somewhat
wrong and I sense there is something missing in the description
of the workflow. When a developer pushes a change to somewhere
else, it must be because the change needs to be shared with
_somebody else_ (but not necessarily with _everybody_).
Without knowing exactly what the desired workflow is, I'd hazard
a guess and would recommend something else, which is hopefully
a more useful way.
When the developer makes that 131345 change in os-lib submodule,
he is acting as a developer of that library and advancing its
state. He wants to add an enhancement so that a particular way
to use it elsewhere (his use in log-merger program perhaps being
the first one of them) can be supported, but the change is not
accepted as the project wide one from os-lib project's point of
view. The change needs to be shared with people in product2
group that want to further work on top of the change he makes in
log-merger project, but not necessarily with everybody in
product2 group, let alone people in product1 group.
That's exactly what a topic branch is about, isn't it?
He has a topic to enhance something in os-lib project, so
whatever the mysterious 131345 can be made into one branch in
os-lib project and given a more meaningful topic name. He can
push that out to os-lib project, and bind its tip in his tree of
product2 superproject at os-lib directory, and push it to
produc2 repository (maybe to its 'master', or maybe also to its
one of the topic branches that houses his work-in-progress).
That way, when somebody from product2 group needs to work on top
of the change he made and pushed out thusly updates, his copy of
os-lib will get the updates to (or perhaps creation of) the
topic branch that contains 131345 change, and he can start
working from where the original developer left off. He can even
fix bugs in the change in that 131345 topic in os-lib project
the original developer made, push that back, and the original
developer can build on top of that change.
^ permalink raw reply
* Re: RFC/RFH submodule handling in big setups
From: Jan Hudec @ 2008-01-07 20:07 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20080107102327.GA12427@pvv.org>
On Mon, Jan 07, 2008 at 11:23:27 +0100, Finn Arne Gangstad wrote:
> 3. each time you push a submodule, do a merge ours to a
> "internal-submodule-tracking" branch, and push to that. Something
> like this in other words:
>
> git fetch origin internal-submodule-tracking
> git merge -s ours origin/internal-submodule-tracking
> git push origin internal-submodule-tracking
> git reset --hard HEAD^1
>
> Issue: feels wrong somehow?
Only one thing feels wrong here -- the merge -s ours. For one thing, the
commit is probably descendant of what was in the internal-submodule-tracking
branch (the branch name should actually have product2 in it's name).
If it is not, you should not artificially make it so, but rewind the branch.
But as Junio already told you, you should really manage the subproject like
a project (because it is a project), so the change should get to a topic
branch where the other superprojects can look at the change and decide
whether they want it or not.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: RFC/RFH submodule handling in big setups
From: Nigel Magnay @ 2008-01-07 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Finn Arne Gangstad, git
In-Reply-To: <7vr6gtzaeq.fsf@gitster.siamese.dyndns.org>
Do you currently use svn?
This feels like the common technique of using svn:externals, where
product1 has
foo repo/foo/trunk
os-abstraction-lib repo/os-abstraction-lib/trunk
product2 has
os-abstraction-lib repo/os-abstraction-lib/trunk
log-merger repos/log-merger/trunk
Where git (if I understand submodules correctly) can't do the above,
because the links are to SHA1s rather than tags or names, so in svn
terms it'd be something like
os-abstraction-lib repo/os-abstraction-lib/trunk@xxx
log-merger repos/log-merger/trunk@yyy
At first I thought the option (4) you suggest (Manually push all
sub-modules to some new branch before pushing the super-module) was
going to be a pain - but actually I came to the conclusion it was
actually better. In our svn world, commits to shared libraries (can)
cause all hell to break loose - it'd actually be an advantage to have
to promote changes into the supermodules (the products in our case).
On Jan 7, 2008 7:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>
> > We're trying to get git to work well with our vision of submodules,
> > and have to figure out how to make submodule fetching and pushing work
> > in a smooth way.
> >
> > This is our situation (simplified):
> >
> > [product1] [product2] ... (supermodules)
> > / \ / \
> > ... [foo] [os-abstraction-lib] [log-merger] ... (submodules)
> >
> >
> > A developer does a modification to the os-abstraction-lib, and a
> > modification to the log-merger that depends on the change in the
> > os-abstraction-lib. He wants this into product2, and doesn't know or
> > care about product1. He doesn't know whether his modification is
> > acceptable or not, or whether his modification will go in before some
> > other modification.
> >
> > He needs some way of pushing his modifications to a branch in the
> > supermodule (e.g. "change-131345"), without interfering with anyone
> > else. The problem is where to push the sub-modules, they need to be
> > available for anyone who wants to get the "change-131345" branch of
> > the product2, but the modifications shouldn't show up anywhere else
> > (yet). Here are solutions we have thought of so far:
>
> The phrase "without interfering with anyone else" feels somewhat
> wrong and I sense there is something missing in the description
> of the workflow. When a developer pushes a change to somewhere
> else, it must be because the change needs to be shared with
> _somebody else_ (but not necessarily with _everybody_).
>
> Without knowing exactly what the desired workflow is, I'd hazard
> a guess and would recommend something else, which is hopefully
> a more useful way.
>
> When the developer makes that 131345 change in os-lib submodule,
> he is acting as a developer of that library and advancing its
> state. He wants to add an enhancement so that a particular way
> to use it elsewhere (his use in log-merger program perhaps being
> the first one of them) can be supported, but the change is not
> accepted as the project wide one from os-lib project's point of
> view. The change needs to be shared with people in product2
> group that want to further work on top of the change he makes in
> log-merger project, but not necessarily with everybody in
> product2 group, let alone people in product1 group.
>
> That's exactly what a topic branch is about, isn't it?
>
> He has a topic to enhance something in os-lib project, so
> whatever the mysterious 131345 can be made into one branch in
> os-lib project and given a more meaningful topic name. He can
> push that out to os-lib project, and bind its tip in his tree of
> product2 superproject at os-lib directory, and push it to
> produc2 repository (maybe to its 'master', or maybe also to its
> one of the topic branches that houses his work-in-progress).
>
> That way, when somebody from product2 group needs to work on top
> of the change he made and pushed out thusly updates, his copy of
> os-lib will get the updates to (or perhaps creation of) the
> topic branch that contains 131345 change, and he can start
> working from where the original developer left off. He can even
> fix bugs in the change in that 131345 topic in os-lib project
> the original developer made, push that back, and the original
> developer can build on top of that change.
>
>
> -
> 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: RFC/RFH submodule handling in big setups
From: Finn Arne Gangstad @ 2008-01-07 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6gtzaeq.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 07, 2008 at 11:46:21AM -0800, Junio C Hamano wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>
> > We're trying to get git to work well with our vision of submodules,
> > and have to figure out how to make submodule fetching and pushing work
> > in a smooth way.
> >
> > This is our situation (simplified):
> >
> > [product1] [product2] ... (supermodules)
> > / \ / \
> > ... [foo] [os-abstraction-lib] [log-merger] ... (submodules)
> >
> > [...]
>
> The phrase "without interfering with anyone else" feels somewhat
> wrong and I sense there is something missing in the description
> of the workflow. When a developer pushes a change to somewhere
> else, it must be because the change needs to be shared with
> _somebody else_ (but not necessarily with _everybody_).
>
> Without knowing exactly what the desired workflow is, I'd hazard
> a guess and would recommend something else, which is hopefully
> a more useful way.
I'll try to explain a bit better, in different ways:
Way 1: Think of product2 as a big repository
I want to use git as if product2 was a single repository containing
all its submodules as directories.
I want to be able to send email patches agains product2 that affect
any number of the submodules. I want to apply these in any order, and
to let them live as topic branches in product2.
Way 2: Changes to several submodules must be "globally atomic"
If I change submodule 1 and submodule 2, I want to be able to commit
both those changes as one atomic change in the supermodule - in a
topic branch. When merging that topic branch in the supermodule, both
changes in the submodules are merged. But NOT BEFORE. The submodules
cannot be pre-merged (hence the need to push them "somewhere")
Way 3: The submodules are not released on their own
Only the products are released, each product has different release
criteria, code freezes, whatever. Syncing of submodules between
products happens rarely (a few times a year maybe). Modifications to
submodules must fit each product's release criteria.
There is usually no one who is responsible for each submodule, they
live their life as part of the supermodule. Anyone can modify a
submodule, but each product has a maintainer who decides what
modifications to the submodules are allowed in that product.
Does this make things clearer in any way?
- Finn Arne
^ permalink raw reply
* Re: RFC/RFH submodule handling in big setups
From: Finn Arne Gangstad @ 2008-01-07 20:59 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20080107200756.GA20892@efreet.light.src>
On Mon, Jan 07, 2008 at 09:07:56PM +0100, Jan Hudec wrote:
> On Mon, Jan 07, 2008 at 11:23:27 +0100, Finn Arne Gangstad wrote:
> > 3. each time you push a submodule, do a merge ours to a
> > "internal-submodule-tracking" branch, and push to that. Something
> > like this in other words:
> >
> > git fetch origin internal-submodule-tracking
> > git merge -s ours origin/internal-submodule-tracking
> > git push origin internal-submodule-tracking
> > git reset --hard HEAD^1
> >
> > Issue: feels wrong somehow?
>
> Only one thing feels wrong here -- the merge -s ours. For one thing, the
> commit is probably descendant of what was in the internal-submodule-tracking
> branch (the branch name should actually have product2 in it's name).
> If it is not, you should not artificially make it so, but rewind the branch.
The idea of the branch is to not have to make thousands of tags as
time passes, just to have a branch that refers to all the commits that
the supermodule refers to in the submodule.
The internal-submodule-tracking branch should look like this:
/ ... etc
m
/ \
m o-commit 3
/ \
m o-commit 2
/ \
. o-commit 1
Where all the "m" commits are just dummy merge commits, the contents
are of no consequence (hence the "merge -s ours" that should always
silently go through). commit 1, 2 and 3, ... are the interesting ones,
they are the sha1s the supermodule refers to in the submodule. They
may or may not have any relationship to eachother. If they _do_ have
a realtionship to eachother, this will be tracked in some other branch
in the submodule.
So the purpose of the internal-submodule-tracking branch is: Have a
branch to push to (you cannot just push a sha1 to nowhere), have
something that refers to the sha1 so that it will not be pruned away,
and have something that refers to the sha1 so it will actually be
_fetched_ by git fetch.
> But as Junio already told you, you should really manage the subproject like
> a project (because it is a project), so the change should get to a topic
> branch where the other superprojects can look at the change and decide
> whether they want it or not.
See another mail I wote, I don't want to manage the subproject like a
separate project (it isn't).
- Finn Arne
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Robin Rosenberg @ 2008-01-07 21:03 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Steffen Prohaska, Peter Karlsson, Git Mailing List
In-Reply-To: <alpine.LSU.1.00.0801071915470.10101@racer.site>
måndagen den 7 januari 2008 skrev du:
> Problem. There is not a single "right". It really depends on the
> project.
Indeed, but the most common SCM's detect binary files automatically,
either by suffix or content analysis, so I think that is what user's expect.
It will be right for more projects that the current behaviour.
-- robin
^ permalink raw reply
* Re: how to use git merge -s subtree?
From: Junio C Hamano @ 2008-01-07 21:04 UTC (permalink / raw)
To: Sean; +Cc: David Soria Parra, git
In-Reply-To: <BAYC1-PASMTP1079A31936B4563801537DAE4E0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> ... Asking for the history of a file does make
> sense. Through path limiting you can ask to see just the subset of history that
> touched a certain file or directory etc..
That's asking for the history of a _path_ (or subset defined by
paths, as in "what changes were made to paths under 'arch/'"),
which is very different from asking "I have B/foo.c -- show me
the history of that _file_".
Remember, David stated:
>> ... So you cannot do git-log B/foo.c as git doesnot know where
>> to search it as it thinks it is in /foo.c not in B/foo.c ...
Notice "as git does not know where to search it" part?
Think --- what does that "it" refer to in that sentence?
The statement is not about paths. If it were about paths, then
the output of "git log B/foo.c" does show what he wants. The
question "git log B/foo.c" asks is "what change were made to the
path at B/foo.c". The changes made to B/foo.c (i.e. what's
shown with the diff headers that begin with "--- a/B/foo.c") are
shown. The changes made to foo.c are not shown.
But that is different from what David is asking. He wants to
know what changes were made to B/foo.c or to foo.c, and wants to
make the choice between the two depend on commit. The reason
you think you can pick between foo.c and B/foo.c is because
there is an illusion that somehow there is an i-node like file
identity that is kept track of, and it is preserved across
renames and merges.
That's keeping track of the history of a _file_.
And as you know, git doesn't do that.
What git does is to keep track of the history of the whole tree,
but prune the parts that are not interesting away when you view
the history. And the pruning can be specified by _PATH_.
See the difference?
^ 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