* Re: [PATCH] git-p4: don't convert utf16 files.
From: Pete Wyckoff @ 2011-08-21 15:21 UTC (permalink / raw)
To: Chris Li
Cc: git, Junio C Hamano, Eberhard Beilharz, Jordan Zimmerman,
Mike Crowe
In-Reply-To: <CANeU7QmGJTr4V-tWzuPnP2P=9eQbGDgQxv2phAVbGXjU5tqYPQ@mail.gmail.com>
christ.li@gmail.com wrote on Fri, 19 Aug 2011 15:50 -0700:
> Some repository has some utf16 files git-p4 don't know
> how to convert. For those files, git-p4 just write the utf8
> files. That is wrong, because git get different file than
> perforce does, causing some windows resource file fail
> to compile.
>
> Using the "p4 print -o tmpfile depotfile" can avoid this
> convertion (and possible failure) all together.
This isn't contrib/fast-import/git-p4. Searching around, I
discovered a 2009 fork of git-p4 that is fairly active. CC-ing
some of the names I found on github.
Here's one such repo:
http://github.com/ermshiperete/git-p4
Git's git-p4 doesn't try to do anything special with utf-16. It
does \r\n mangling, but not $Keyword$ removal, then just streams
it to disk however p4 sends it. That's close to what you're
trying to do here.
-- Pete
> Signed-off-by: Chris Li <git@chrisli.org>
>
> ---
> git-p4 | 11 +++++------
> 1 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/git-p4 b/git-p4
> index 672b0c2..0c6a5cc 100755
> --- a/git-p4
> +++ b/git-p4
> @@ -755,12 +755,11 @@ class P4FileReader:
> break
>
> if header['type'].startswith('utf16'):
> - try:
> - text = textBuffer.getvalue().encode('utf_16')
> - except UnicodeDecodeError:
> - # File checked in to Perforce has an error. Try
> without encoding
> - print "Corrupt UTF-16 file in Perforce: %s" %
> header['depotFile']
> - text = textBuffer.getvalue()
> + # Don't even try to convert utf16. Ask p4 to write
> the file directly.
> + tmpFile = tempfile.NamedTemporaryFile()
> + P4Helper().p4_system("print -o %s %s"%(tmpFile.name,
> header['depotFile']))
> + text = open(tmpFile.name).read()
> + tmpFile.close()
> else:
> text = textBuffer.getvalue()
> textBuffer.close()
> --
> 1.7.6
> --
> 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: Site dependent repositories
From: Jens Lehmann @ 2011-08-21 16:14 UTC (permalink / raw)
To: sabrown256; +Cc: Stewart A. Brown, git
In-Reply-To: <4E507C05.2090700@sbcglobal.net>
Am 21.08.2011 05:31, schrieb Stewart A. Brown:
> I am wondering whether or not git has the functionality to handle
> my situation.
>
> I have git repositories at multiple sites. At each site the git repository
> has site dependent sources. Each repository is organised something
> like:
>
> top/a/local
> b
> c/d/extensions
> e
>
> The directories top, a, b, c, d, and e have sources that need to be
> pushed or pulled between the repositories at all sites. The directories
> 'local' and 'extensions' have sources that must be managed within sites
> but never pushed or pulled between sites.
>
> The ignore mechanism will not suffice because the files in 'local' and
> 'extensions' must be source managed. I have looked a bit into
> submodules, filters, and hooks. None of these jumps out as obvious, but
> they are rich mechanisms with plenty of subtleties.
>
> Does git have a way of letting me do this?
It would work if you could set it up like this:
top/shared
non-shared-stuff
where "top" is your git repository, "shared" is a submodule you put all the
non-site specific stuff in and have that version controlled together with
your local stuff. If you can't rearrange your directory tree you might be
able to use symlinks to achieve that layout:
top/a/local -> ../local
b
c/d/extensions -> ../../extensions
e
top/extension
top/local
where "a" is your shared submodule that lives together with "extensions" and
"local" in the top level repo.
^ permalink raw reply
* Re: Failure cloning from a separate-git-dir repository
From: Junio C Hamano @ 2011-08-21 18:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Richard Tibbitt, git
In-Reply-To: <CACsJy8A4kvjn5Bgo6FtS+x4z=CRz8ctoDHh7D8XV3frOjDVfbw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Sun, Aug 21, 2011 at 1:56 AM, Richard Tibbitt <gitlist@lazyprune.com> wrote:
>> call git clone repo2git\.git clone2
>> fatal: repository 'repo2git\.git' does not exist
>>
>> I guess this must be a peculiarity of msysgit on windows.
>
> Yes. Try "call git clone repo2git/.git clone2" (forward slash). The
> forward slash is hard coded some places in git-clone. I just want to
> make sure you dont hit another problem.
As "fetch from bundle" (2e0afaf (Add git-bundle: move objects and
references by archive, 2007-02-22)) predates the "gitdir:" support
(b44ebb1 (Add platform-independent .git "symlink", 2008-02-20)) by a wide
margin, I wouldn't be surprised at all if the logic went "If the name can
be stat()ed and is a regular file, it must be a bundle. Otherwise it is a
local clone if it is a directory. All else ask the transport and see what
it says".
Why can't it be "git clone repo2git clone2" in the first place?
^ permalink raw reply
* Re: [PATCH 1/2] clone: allow to clone from .git file
From: Junio C Hamano @ 2011-08-21 18:54 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1313927890-21227-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> + else if (S_ISREG(st.st_mode) && st.st_size > 8) {
> + /* Despite the name read_gitfile_gently can be
> + cruel on non .git file, check for signature
> + ourselves */
Didn't somebody add "is this '.git' thing a valid git metadirectory?" API
quite recently for exactly this?
^ permalink raw reply
* Re: [PATCH] git-p4: don't convert utf16 files.
From: Chris Li @ 2011-08-21 19:09 UTC (permalink / raw)
To: Pete Wyckoff
Cc: git, Junio C Hamano, Eberhard Beilharz, Jordan Zimmerman,
Mike Crowe
In-Reply-To: <20110821152156.GA30299@arf.padd.com>
On Sun, Aug 21, 2011 at 8:21 AM, Pete Wyckoff <pw@padd.com> wrote:
>> Using the "p4 print -o tmpfile depotfile" can avoid this
>> convertion (and possible failure) all together.
>
> This isn't contrib/fast-import/git-p4. Searching around, I
> discovered a 2009 fork of git-p4 that is fairly active. CC-ing
> some of the names I found on github.
Oops. I forget I am trying some other git-p4 and this patch is
not for git-core. The git-p4 in git-core repository has the same
problem. I was original using the git-core one, hit the bug. Then
I try some other branch and found the same problem, I just forget
which git repository I am at. Silly me.
Let me redo a patch for git.
>
> Here's one such repo:
>
> http://github.com/ermshiperete/git-p4
>
> Git's git-p4 doesn't try to do anything special with utf-16. It
> does \r\n mangling, but not $Keyword$ removal, then just streams
> it to disk however p4 sends it. That's close to what you're
> trying to do here.
No, it is not the same. Here is what I find out. If you ask use
"p4 print" to fetch a perforce utf16 file, perforce convert that file into
utf8 before it send out to stdout. I guess the perforce guys assume
p4 print is used for terminal console. If the git-p4 just stream to disk,
then you those file are effective checkout as utf8, which is about
half the size of the original utf16 file.
I never like those utf16 files, I think those file should be check in
as binary. But some one did check in the utf16 in the repository I
use at work, Now I have to deal with it. I guess the reason perforce
want to know about utf16 is to do the \r\n conversion properly on
those utf16 files. The file in question is the windows .mc file.
It contain different language translation of the error message.
So git-p4 in git-core effectively converted the perforce utf16 file to
utf8 during import.
However, if I do "p4 print -o filename". Perforce will write the file in
the original utf16 format. I don't need to do the utf8 to utf16 conversion,
which can failed and it does in my case.
The git-p4 in git-core need the same treatment. I will work out a patch
and resubmit that later.
Thanks
Chris
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-08-21 19:48 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <20110818044555.GA20752@elie.gateway.2wire.net>
Hi Jonathan,
On 17 August 2011 21:45, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Hilco,
>
> Hilco Wijbenga wrote:
>
>> It would be really nice, though, if Git could somehow
>> "stash" such files when checking out a different branch. In general, I
>> would prefer if uncommitted changes and untracked and/or ignored files
>> stuck to the branch where they were created.
>
> This is just a random guess, but: wouldn't it be convenient in this
> workflow to have a separate worktree for each branch you are working
> on? That way, switching branches would not carry over unwanted state
> or throw away valuable state, clobber timestamps that "make" pays
> attention to, etc.
>
> If I am understanding correctly, then the git-new-workdir script
> from contrib/workdir might help. (Note, though, that it comes with
> some caveats. A quick mailing list search should find them.)
Yes, both a separate clone and git-new-workdir (which I've just
started using) would work.
I'm not entirely happy with this solution, though. It means having to
create an Eclipse workspace per branch, this is a *lot* of work. (This
is mostly Eclipse's fault but still.) One of the exceedingly
attractive features of Git is the easy branching and merging.
Branching is now no longer easy. :-(
I assume it would be possible for Git to move untracked/ignored files
out of the way when checking out a different branch? (And moving them
back in when going back to that branch.) Are there any objections to
doing this? I.e. would it be a bad idea for some reason?
So, in essence, would it be possible (and desirable) to associate
untracked/ignored files with a particular branch? And only show them
when that branch is checked out?
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-08-21 20:25 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAMOZ1BsZvXsnnWAPXR7UGKdqOMwuGB-ffaAPk55U_1dcjZUcDw@mail.gmail.com>
On 17 August 2011 22:52, Michael Witten <mfwitten@gmail.com> wrote:
> On Wed, Aug 17, 2011 at 21:23, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> It would be really nice, though, if Git could somehow
>> "stash" such files when checking out a different branch. In general, I
>> would prefer if uncommitted changes and untracked and/or ignored files
>> stuck to the branch where they were created.
>
> As an aside, the problem here is likely a manifestation of the fact
> that nobody understands what a branch is; the word 'branch' is
> TERRIBLE, as everyone has a different idea for what that should mean.
> In my opinion, `git branch' should become `git ref' or the like.
Are you saying that Git's branches are different from branches in
other SCMs? How does my understanding of "branch" hinder me in the
above scenario? Am I doing something wrong?
Isn't a branch simply a way to track changes separately?
^ permalink raw reply
* Merging one file only
From: Maïeul @ 2011-08-21 20:33 UTC (permalink / raw)
To: git
Hello,
my problem is :
- I have 2 branches : "master" and "sty"
- In the branch sty, I have commit that i don't want to merge on the branch
master. The only file that I want merge are the *dtx files.
My question is : how can i do to merge *dtx files from "sty" to "master",
and have log of commit on the *dtx ? Is it possible ?
Thank a lot !!
--
View this message in context: http://git.661346.n2.nabble.com/Merging-one-file-only-tp6709333p6709333.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Branches & directories
From: Michael Witten @ 2011-08-21 20:53 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi2r9DT3Y-GxivTZRaNVi=qLOy5=QpQ-_YysOkgqy3iGRQ@mail.gmail.com>
On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
<hilco.wijbenga@gmail.com> wrote:
> Isn't a branch simply a way to track changes separately?
Well, what does that mean, really? You can certainly use branches to
help you achieve that goal.
In git usage, a `branch' is just a human-readable name for any given
commit object; it points to a commit object, and you can change to
which commit it points. Furthermore, to help you work with commit
lineages, some of the git machinery updates these branches (or
`pointers', if you like) automatically (for instance, when you make a
new commit object with `git commit', then the `current branch' is
updated to point to the newly created commit object).
Of course, 2 different branches may be used to point to the same commit object.
You should really think of your repository as a giant web of commit
objects (or, more technically, as a directed acyclic graph where each
node is a commit object); a commit object can point 'backwards'
towards its parent commit objects. A branch (like `master') just
points to one of these commit objects at any given time (that is, a
branch just gives a nice human-readable label by which to reference
one of these commit objects at any given time).
See here too:
http://slashdot.org/comments.pl?sid=2350536&cid=36903136
^ permalink raw reply
* Re: Merging one file only
From: Michael Witten @ 2011-08-21 21:32 UTC (permalink / raw)
To: Maïeul; +Cc: git
In-Reply-To: <1313958819073-6709333.post@n2.nabble.com>
On Sun, Aug 21, 2011 at 20:33, Maïeul <maieul@maieul.net> wrote:
> Hello,
>
> my problem is :
> - I have 2 branches : "master" and "sty"
> - In the branch sty, I have commit that i don't want to merge on the branch
> master. The only file that I want merge are the *dtx files.
>
> My question is : how can i do to merge *dtx files from "sty" to "master",
> and have log of commit on the *dtx ? Is it possible ?
There are a number of ways to do this, some more general than others.
Do you know all of the names of the files for which you don't want
associated commits? Do the files that you don't want get changed in
some of the commits that you do want?
^ permalink raw reply
* Re: Merging one file only
From: Maïeul Rouquette @ 2011-08-21 21:35 UTC (permalink / raw)
Cc: git
In-Reply-To: <CAMOZ1BvY13ynmtCkhFNU9Dc8PqwVQUrp8ham5zHrdq2vbMY5JQ@mail.gmail.com>
Le 21 août 2011 à 23:32, Michael Witten a écrit :
> On Sun, Aug 21, 2011 at 20:33, Maïeul <maieul@maieul.net> wrote:
>> Hello,
>>
>> my problem is :
>> - I have 2 branches : "master" and "sty"
>> - In the branch sty, I have commit that i don't want to merge on the branch
>> master. The only file that I want merge are the *dtx files.
>>
>> My question is : how can i do to merge *dtx files from "sty" to "master",
>> and have log of commit on the *dtx ? Is it possible ?
>
> There are a number of ways to do this, some more general than others.
>
> Do you know all of the names of the files for which you don't want
> associated commits? Do the files that you don't want get changed in
> some of the commits that you do want?
I found the solution "git merge hashofcommit". My commits one the file are only on the file, so the solution is very simple !
Thank for helping :)-
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-08-21 21:37 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAMOZ1BvpnP_729YOHrrPW3B8wa5c4cLyD_qAQ5rTuy0JqNiiXg@mail.gmail.com>
On 21 August 2011 13:53, Michael Witten <mfwitten@gmail.com> wrote:
> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
> <hilco.wijbenga@gmail.com> wrote:
>> Isn't a branch simply a way to track changes separately?
>
> Well, what does that mean, really? You can certainly use branches to
> help you achieve that goal.
It means my commits are chained together separate from, say, master.
> In git usage, a `branch' is just a human-readable name for any given
> commit object; it points to a commit object, and you can change to
> which commit it points. Furthermore, to help you work with commit
> lineages, some of the git machinery updates these branches (or
> `pointers', if you like) automatically (for instance, when you make a
> new commit object with `git commit', then the `current branch' is
> updated to point to the newly created commit object).
>
> Of course, 2 different branches may be used to point to the same commit object.
>
> You should really think of your repository as a giant web of commit
> objects (or, more technically, as a directed acyclic graph where each
> node is a commit object); a commit object can point 'backwards'
> towards its parent commit objects. A branch (like `master') just
> points to one of these commit objects at any given time (that is, a
> branch just gives a nice human-readable label by which to reference
> one of these commit objects at any given time).
Yes, I agree with all of that (especially the last sentence). I don't
see how it changes the concept of a branch is, though. You are, I
think, simply listing the technical implementation.
> See here too:
>
> http://slashdot.org/comments.pl?sid=2350536&cid=36903136
Because of the revision number you have to go "the wrong way". Any
single commit can have many children but a branch only points to a
single, unique commit (or at least that's how I understand it).
I feel like we're talking in circles. I get (and even agree with) what
you're saying but I don't see how it changes the concept of a branch.
In any case, what I'm more interested in is knowing whether we can
(optionally) add state (i.e. untracked/ignored files and unstaged
changes) to a branch.
^ permalink raw reply
* Merge after directory rename ?
From: Marcin Wiśnicki @ 2011-08-21 21:41 UTC (permalink / raw)
To: git
Is it possible to merge files after performing directory renames in such
way that new files will end up in renamed directories ?
For example:
1. [master] add dir1/file1
2. [branch1] branch from master
3. [branch1] add dir1/file2
4. [master] rename dir1 to dir2
5. [master] merge branch1
Where it should notice that dir1=>dir2 and therefore {dir1=>dir2}/file2.
Currently I end up with dir1/file2 which is undesirable as it breaks
refactorings and requires a lot of manual effort to clean-up.
^ permalink raw reply
* Re: Merging one file only
From: PJ Weisberg @ 2011-08-21 21:52 UTC (permalink / raw)
To: Maïeul Rouquette; +Cc: git@vger.kernel.org
In-Reply-To: <6EE456FC-9671-4CAF-9067-743AE2526717@maieul.net>
On Sunday, August 21, 2011, Maïeul Rouquette <maieul@maieul.net> wrote:
>
> Le 21 août 2011 à 23:32, Michael Witten a écrit :
>
>> On Sun, Aug 21, 2011 at 20:33, Maïeul <maieul@maieul.net> wrote:
>>> Hello,
>>>
>>> my problem is :
>>> - I have 2 branches : "master" and "sty"
>>> - In the branch sty, I have commit that i don't want to merge on the branch
>>> master. The only file that I want merge are the *dtx files.
>>>
>>> My question is : how can i do to merge *dtx files from "sty" to "master",
>>> and have log of commit on the *dtx ? Is it possible ?
>>
>> There are a number of ways to do this, some more general than others.
>>
>> Do you know all of the names of the files for which you don't want
>> associated commits? Do the files that you don't want get changed in
>> some of the commits that you do want?
> I found the solution "git merge hashofcommit". My commits one the file are only on the file, so the solution is very simple !
> Thank for helping :)-
Good if the commits you don't want come *after* the commits you do
want. Use "git cherry-pick <hash>" if you want one commit and *not*
all the commits leading up to it.
^ permalink raw reply
* Re: [PATCH 2/2] demonstrate format-callback used in combined diff
From: Fredrik Gustafsson @ 2011-08-21 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Gustafsson, git, hvoigt, jens.lehmann
In-Reply-To: <7vd3g0zj3l.fsf_-_@alter.siamese.dyndns.org>
Thank you. GSoC is now finished and I have examans next week that needs
my attention. I will continue finish what I started but won't be able to
do so until the end of the weak. Just so you know...
/Fredrik Gustafsson
^ permalink raw reply
* Re: Malformed branch name in fast-export when specifying non-HEAD/branch revision
From: Sverre Rabbelier @ 2011-08-21 22:29 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Elijah Newren, Owen Stephens, git
In-Reply-To: <20110817231922.GA28966@sigill.intra.peff.net>
Heya,
On Wed, Aug 17, 2011 at 16:19, Jeff King <peff@peff.net> wrote:
> On Wed, Aug 17, 2011 at 03:30:14PM -0700, Junio C Hamano wrote:
>
>> You can think of "fast-export" an off-line "push" command [*1*]; instead
>> of giving a random commit object, e.g. "git fast-export HEAD~1", that can
>> not be used as a ref, you can use the refspec notation to tell where the
>> result should go, e.g. "git fast-export HEAD~1:refs/heads/a-bit-older",
>> from the command line of fast-export.
>>
>> I suspect that also may clarify what Sverre was trying to do in his recent
>> series. The root cause of both this and the issue Sverre wanted to fix is
>> the design mistake of fast-export that tries to reuse the notation of
>> object range specification for a different purpose of telling which "ref"
>> to update, I think.
>
> Yes, this was the conclusion I came to when I looked at this a month or
> so ago. You really need to give fast-export a mapping of objects to
> refnames, and it should output ref names _only_ for the mapping. That
> would handle this "not a ref" case, but would also let you push
> "refs/heads/foo" when it is equivalent to "refs/heads/master", without
> fast-export mentioning "refs/heads/master" at all.
Does this bring any new insights into how the problem I was pointing
out (trying to push next if master points at the same commit does
nothing) could/should be solved?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Branches & directories
From: Michael Witten @ 2011-08-21 23:06 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi3OEFg7-OeQM0fvD69gf-5oPQ239CGy9nN0Waas8EM3Bg@mail.gmail.com>
On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> On 21 August 2011 13:53, Michael Witten <mfwitten@gmail.com> wrote:
>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
>> <hilco.wijbenga@gmail.com> wrote:
>>> Isn't a branch simply a way to track changes separately?
>>
>> Well, what does that mean, really? You can certainly use branches to
>> help you achieve that goal.
>
> It means my commits are chained together separate from, say, master.
Well, that's not what a git branch provides in general.
>> In git usage, a `branch' is just a human-readable name for any given
>> commit object; it points to a commit object, and you can change to
>> which commit it points. Furthermore, to help you work with commit
>> lineages, some of the git machinery updates these branches (or
>> `pointers', if you like) automatically (for instance, when you make a
>> new commit object with `git commit', then the `current branch' is
>> updated to point to the newly created commit object).
>>
>> Of course, 2 different branches may be used to point to the same commit object.
>>
>> You should really think of your repository as a giant web of commit
>> objects (or, more technically, as a directed acyclic graph where each
>> node is a commit object); a commit object can point 'backwards'
>> towards its parent commit objects. A branch (like `master') just
>> points to one of these commit objects at any given time (that is, a
>> branch just gives a nice human-readable label by which to reference
>> one of these commit objects at any given time).
>
> Yes, I agree with all of that (especially the last sentence). I don't
> see how it changes the concept of a branch is, though. You are, I
> think, simply listing the technical implementation.
No, I'm simply listing the reality of what a branch is.
> ...
>
> I feel like we're talking in circles. I get (and even agree with) what
> you're saying but I don't see how it changes the concept of a branch.
>
> In any case, what I'm more interested in is knowing whether we can
> (optionally) add state (i.e. untracked/ignored files and unstaged
> changes) to a branch.
No, because a branch doesn't IN ANY WAY provide the structure for that
kind of thing. Of course, you could use what git calls a 'branch' in
order to implement what you imply is a 'branch', but git's concept of
a branch and your concept of a branch are not at all the same concept
(which is why the term 'branch' is so unfortunate).
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-08-21 23:35 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAMOZ1BvHKTPPmfB7Jx+y4OeRv-uwjmQkscXaRr-vEEy30G_Kdw@mail.gmail.com>
On 21 August 2011 16:06, Michael Witten <mfwitten@gmail.com> wrote:
> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> On 21 August 2011 13:53, Michael Witten <mfwitten@gmail.com> wrote:
>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
>>> <hilco.wijbenga@gmail.com> wrote:
>>>> Isn't a branch simply a way to track changes separately?
>>>
>>> Well, what does that mean, really? You can certainly use branches to
>>> help you achieve that goal.
>>
>> It means my commits are chained together separate from, say, master.
>
> Well, that's not what a git branch provides in general.
Er, so what *does* a Git branch provide then?
>> I feel like we're talking in circles. I get (and even agree with) what
>> you're saying but I don't see how it changes the concept of a branch.
>>
>> In any case, what I'm more interested in is knowing whether we can
>> (optionally) add state (i.e. untracked/ignored files and unstaged
>> changes) to a branch.
>
> No, because a branch doesn't IN ANY WAY provide the structure for that
> kind of thing.
Obviously, we'd need to expand that structure.
I tried (ab)using git stash to get what I want but it ignores
untracked/ignored files (not a big surprise, of course). It seems the
functionality is almost there. If I could just combine git checkout
with git stash (and have it work with untracked/ignored files) in a
script or alias, I'd be a happy camper. I'll have to give it some more
thought.
> Of course, you could use what git calls a 'branch' in
> order to implement what you imply is a 'branch', but git's concept of
> a branch and your concept of a branch are not at all the same concept
> (which is why the term 'branch' is so unfortunate).
You've completely lost me. You may very well be right but all I see is
that you're pointing out how branches are implemented in Git.
^ permalink raw reply
* Re: Merge after directory rename ?
From: Michael Witten @ 2011-08-21 23:45 UTC (permalink / raw)
To: Marcin Wiśnicki; +Cc: git
In-Reply-To: <j2ru2h$cd$1@dough.gmane.org>
2011/8/21 Marcin Wiśnicki <mwisnicki@gmail.com>:
> Is it possible to merge files after performing directory renames in such
> way that new files will end up in renamed directories ?
>
> For example:
> 1. [master] add dir1/file1
> 2. [branch1] branch from master
> 3. [branch1] add dir1/file2
> 4. [master] rename dir1 to dir2
> 5. [master] merge branch1
>
> Where it should notice that dir1=>dir2 and therefore {dir1=>dir2}/file2.
>
> Currently I end up with dir1/file2 which is undesirable as it breaks
> refactorings and requires a lot of manual effort to clean-up.
Part of the assumption for someone working on `branch1' might be that
`dir1/file2' is in fact in `dir1'. The rename via `master' conflicts
with that assumption. In this case, a full-blown conflict might be
useful.
However, suppose that the author who is working with `master' doesn't
need `dir1', but the author who is working with `branch1' does need it
INDEPENDENTLY:
1. [master] add dir2/file1
2. [branch1] branch from master
3. [branch1] add dir1/file2
4. [master] add dir1/file3
5. [master] rename dir1/file3 to dir3/file3
6. [master] merge branch1
In that case, you'd want `dir1/file2' from the `branch1' work to be
silently created rather than automatically renamed to `dir3/file3'.
This should not result in a conflict or a rename.
So, from your grievance, I suppose that git currently assumes the
latter case (and hence, gives no indication of a possible conflict).
Perhaps git could be improved here at least in terms of a warning.
Perhaps the merger could request that directory renames be considered
conflicts or enforced, but this would have to involve the intent of
the merger me thinks (using command line flags).
^ permalink raw reply
* Re: Merge after directory rename ?
From: Michael Witten @ 2011-08-21 23:53 UTC (permalink / raw)
To: Marcin Wiśnicki; +Cc: git
In-Reply-To: <CAMOZ1BukGPZt8gJh0J4EHRrPHv5teAdnkNT+gZJa9mX=2ohFOw@mail.gmail.com>
2011/8/21 Michael Witten <mfwitten@gmail.com>:
> 2011/8/21 Marcin Wiśnicki <mwisnicki@gmail.com>:
>> Is it possible to merge files after performing directory renames in such
>> way that new files will end up in renamed directories ?
>>
>> For example:
>> 1. [master] add dir1/file1
>> 2. [branch1] branch from master
>> 3. [branch1] add dir1/file2
>> 4. [master] rename dir1 to dir2
>> 5. [master] merge branch1
>>
>> Where it should notice that dir1=>dir2 and therefore {dir1=>dir2}/file2.
>>
>> Currently I end up with dir1/file2 which is undesirable as it breaks
>> refactorings and requires a lot of manual effort to clean-up.
>
> Part of the assumption for someone working on `branch1' might be that
> `dir1/file2' is in fact in `dir1'. The rename via `master' conflicts
> with that assumption. In this case, a full-blown conflict might be
> useful.
>
> However, suppose that the author who is working with `master' doesn't
> need `dir1', but the author who is working with `branch1' does need it
> INDEPENDENTLY:
>
> 1. [master] add dir2/file1
> 2. [branch1] branch from master
> 3. [branch1] add dir1/file2
> 4. [master] add dir1/file3
> 5. [master] rename dir1/file3 to dir3/file3
> 6. [master] merge branch1
>
> In that case, you'd want `dir1/file2' from the `branch1' work to be
> silently created rather than automatically renamed to `dir3/file3'.
> This should not result in a conflict or a rename.
>
> So, from your grievance, I suppose that git currently assumes the
> latter case (and hence, gives no indication of a possible conflict).
> Perhaps git could be improved here at least in terms of a warning.
> Perhaps the merger could request that directory renames be considered
> conflicts or enforced, but this would have to involve the intent of
> the merger me thinks (using command line flags).
Importantly, note that I used only file names in my example, specifically:
5. [master] rename dir1/file3 to dir3/file3
rather than mirroring your example by writing:
5. [master] rename dir1 to dir3
This is because git fundamentally tracks content, and paths are just
one kind of content associated with another blob of content.
Consequently, git really knows next to nothing about directories, so
it's not too surprising that git doesn't bother finding such a
DIRECTORY rename anyway (at most, git would detect a FILE rename, and
your FILE `dir1/file2' has nothing to do with, say, the FILE
`dir1/file1' being renamed `dir2/file1').
Still, some command line switches could be useful to help the user
express to git what should be going on in a case such as yours.
^ permalink raw reply
* Re: Branches & directories
From: Michael Witten @ 2011-08-22 0:07 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi0b2w8t53U7PSvVwVxZF9O0HTyfCR4vy+-baBjqCDeNJA@mail.gmail.com>
On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> On 21 August 2011 16:06, Michael Witten <mfwitten@gmail.com> wrote:
>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>> On 21 August 2011 13:53, Michael Witten <mfwitten@gmail.com> wrote:
>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
>>>> <hilco.wijbenga@gmail.com> wrote:
>>>>> Isn't a branch simply a way to track changes separately?
>>>>
>>>> Well, what does that mean, really? You can certainly use branches to
>>>> help you achieve that goal.
>>>
>>> It means my commits are chained together separate from, say, master.
>>
>> Well, that's not what a git branch provides in general.
>
> Er, so what *does* a Git branch provide then?
I think my other replies (including the link) repeat myself quite enough.
A branch is just a pointer. That's it.
Quit saying `branch' to yourself. Start saying `pointer' or
`reference' or `commit label' or even `special tag'.
>>> I feel like we're talking in circles. I get (and even agree with) what
>>> you're saying but I don't see how it changes the concept of a branch.
>>>
>>> In any case, what I'm more interested in is knowing whether we can
>>> (optionally) add state (i.e. untracked/ignored files and unstaged
>>> changes) to a branch.
>>
>> No, because a branch doesn't IN ANY WAY provide the structure for that
>> kind of thing.
>
> Obviously, we'd need to expand that structure.
>
> I tried (ab)using git stash to get what I want but it ignores
> untracked/ignored files (not a big surprise, of course). It seems the
> functionality is almost there. If I could just combine git checkout
> with git stash (and have it work with untracked/ignored files) in a
> script or alias, I'd be a happy camper. I'll have to give it some more
> thought.
This cobbling together of git's components for this purpose is
actually a fairly frequent story on this list. Either git does indeed
need something more substantial as a `branch', or people (meaning you)
need to change the way they think (and I'm not sure which solution
would be best, honestly).
If there is a change, then what is currently called a `branch' should
be renamed explicitly to `pointer' or a `reference' or something like
that.
>> Of course, you could use what git calls a 'branch' in
>> order to implement what you imply is a 'branch', but git's concept of
>> a branch and your concept of a branch are not at all the same concept
>> (which is why the term 'branch' is so unfortunate).
>
> You've completely lost me. You may very well be right but all I see is
> that you're pointing out how branches are implemented in Git.
That last sentence and your earlier sentence:
> Obviously, we'd need to expand that structure.
vindicate everything I've said about the choice of nomenclature. The
term `branch' is a TERRIBLE choice.
^ permalink raw reply
* Re: [PATCH v2 1/4] git-p4: Allow setting rename/copy detection threshold.
From: Vitor Antunes @ 2011-08-22 0:09 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Junio C Hamano, git, Tor Arvid Lund
In-Reply-To: <20110820111956.GA5893@arf.padd.com>
On Sat, 20 Aug 2011 07:19:56 -0400
Pete Wyckoff <pw@padd.com> wrote:
> I was imagining you would not use "--bool", and parse everything
> yourself. But I see your point, and letting "1" mean "-M1" as
> opposed to "-M" is probably okay too. I'm not particularly
> worked up about which way that goes.
I decided to only add --bool to detectCopiesHarder, at least for now.
Will send a new set of patches shortly.
--
Vitor Antunes
^ permalink raw reply
* Re: [PATCH/RFC 2/2] git-p4: Add complex test case for branch import
From: Vitor Antunes @ 2011-08-22 0:13 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Tor Arvid Lund
In-Reply-To: <20110820191203.GC7135@arf.padd.com>
On Sat, 20 Aug 2011 15:12:03 -0400
Pete Wyckoff <pw@padd.com> wrote:
> Style edits.
>
> -- Pete
I still need some help on the code part of this RFC patch. I really do
not like the way it is implemented. Do you see other possible ways of
achieving the same algorithm?
Thanks,
--
Vitor Antunes
^ permalink raw reply
* Re: Merge after directory rename ?
From: Marcin Wiśnicki @ 2011-08-22 0:32 UTC (permalink / raw)
To: git
In-Reply-To: <CAMOZ1Bt8cP146xiDXfSA-naSOaS3AC8pUZgW12=3TMg2JGCD=w@mail.gmail.com>
On Sun, 21 Aug 2011 23:53:34 +0000, Michael Witten wrote:
> Importantly, note that I used only file names in my example,
> specifically:
>
> 5. [master] rename dir1/file3 to dir3/file3
>
> rather than mirroring your example by writing:
>
> 5. [master] rename dir1 to dir3
>
> This is because git fundamentally tracks content, and paths are just one
> kind of content associated with another blob of content. Consequently,
I know it tracks content, yet it puts effort to detect file renames.
I want it to also detect directory renames, detecting it should be quite
easy.
> git really knows next to nothing about directories, so it's not too
> surprising that git doesn't bother finding such a DIRECTORY rename
> anyway (at most, git would detect a FILE rename, and your FILE
> `dir1/file2' has nothing to do with, say, the FILE `dir1/file1' being
> renamed `dir2/file1').
>
> Still, some command line switches could be useful to help the user
> express to git what should be going on in a case such as yours.
I would prefer it to be fully automatic :)
Or at least detect/warn about tree conflict.
Directory renames can happen quite frequently when working with Java/C#
and it is unreasonable to expect that lazy user will have to keep track of
it manually (with huge number of files it's impossible).
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-08-22 0:47 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAMOZ1BtOkwVbC3RyJVQb7K1DRMnJf3_omn7zrkzoE48Ayu7HBg@mail.gmail.com>
On 21 August 2011 17:07, Michael Witten <mfwitten@gmail.com> wrote:
> On Sun, Aug 21, 2011 at 23:35, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>> On 21 August 2011 16:06, Michael Witten <mfwitten@gmail.com> wrote:
>>> On Sun, Aug 21, 2011 at 21:37, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>>> On 21 August 2011 13:53, Michael Witten <mfwitten@gmail.com> wrote:
>>>>> On Sun, Aug 21, 2011 at 13:42 -0700, Hilco Wijbenga
>>>>> <hilco.wijbenga@gmail.com> wrote:
>>>>>> Isn't a branch simply a way to track changes separately?
>>>>>
>>>>> Well, what does that mean, really? You can certainly use branches to
>>>>> help you achieve that goal.
>>>>
>>>> It means my commits are chained together separate from, say, master.
>>>
>>> Well, that's not what a git branch provides in general.
>>
>> Er, so what *does* a Git branch provide then?
>
> I think my other replies (including the link) repeat myself quite enough.
>
> A branch is just a pointer. That's it.
>
> Quit saying `branch' to yourself. Start saying `pointer' or
> `reference' or `commit label' or even `special tag'.
:-) Again, we are going in circles. I *know* a branch is just a
pointer. So what? To me, that's just the implementation. Why is that
relevant? What am I missing?
>>>> I feel like we're talking in circles. I get (and even agree with) what
>>>> you're saying but I don't see how it changes the concept of a branch.
>>>>
>>>> In any case, what I'm more interested in is knowing whether we can
>>>> (optionally) add state (i.e. untracked/ignored files and unstaged
>>>> changes) to a branch.
>>>
>>> No, because a branch doesn't IN ANY WAY provide the structure for that
>>> kind of thing.
>>
>> Obviously, we'd need to expand that structure.
>>
>> I tried (ab)using git stash to get what I want but it ignores
>> untracked/ignored files (not a big surprise, of course). It seems the
>> functionality is almost there. If I could just combine git checkout
>> with git stash (and have it work with untracked/ignored files) in a
>> script or alias, I'd be a happy camper. I'll have to give it some more
>> thought.
>
> This cobbling together of git's components for this purpose is
> actually a fairly frequent story on this list. Either git does indeed
> need something more substantial as a `branch', or people (meaning you)
> need to change the way they think (and I'm not sure which solution
> would be best, honestly).
I don't think that changing the way I think would be very effective. I
still have to get my work done. And I don't want build artifacts from
one "pointer" ;-) leak into the working directory of another "pointer"
just because I changed "pointers". (I'm sorry, "pointer" just doesn't
work for me.)
How is this normally resolved? What do the Linux kernel developers do
when changing or creating a branch? Do they do some sort of "clean"
first?
And I'm getting quite close with "git ls-files -io --exclude-standard
--directory". :-) The cobbling-together-of-components approach looks
promising. ;-)
> If there is a change, then what is currently called a `branch' should
> be renamed explicitly to `pointer' or a `reference' or something like
> that.
Quite possibly but it seems to me that this is too low level. I think
there are already too many places where Git's implementation leaks
into its API. E.g., anything explicitly related to the index.
>>> Of course, you could use what git calls a 'branch' in
>>> order to implement what you imply is a 'branch', but git's concept of
>>> a branch and your concept of a branch are not at all the same concept
>>> (which is why the term 'branch' is so unfortunate).
>>
>> You've completely lost me. You may very well be right but all I see is
>> that you're pointing out how branches are implemented in Git.
>
> That last sentence and your earlier sentence:
>
>> Obviously, we'd need to expand that structure.
>
> vindicate everything I've said about the choice of nomenclature. The
> term `branch' is a TERRIBLE choice.
^ 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