RE: Feature Request - Hide ignored files before checkout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm glad we are on the same page now and thanks for bringing in others.

" Not wanting the files in the repository seems to be in conflict with the
desire to have them under its control (i.e., disappear/reappear behavior.) "
Sorry, when I said I didn't want them in the repository, I meant I wanted
them there (in the repository folder), but not within Git commit logs and
not being tracked, etc.
Committing binary/OS specific files just doesn't sit right with me and I am
sure many others.

"... but why do you need them to disappear?  Why not just put them somewhere
where they can be used when needed and left alone when not?"
I could do that (keep them in a folder that will be left alone), but in my
specific case it would mean the executable files (ignored files placed in
this new folder) will not execute because of the change in location and
hence would require a lot of code change to suit.

>From my perspective I don't see the harm in having this as a new feature
(via flags in the .gitignore file, if you don't want to make it default
behaviour). Is there some reason I don't know about, maybe to do with the
Git source code?

-----Original Message-----
From: chris.rorvick@xxxxxxxxx [mailto:chris.rorvick@xxxxxxxxx] On Behalf Of
Chris Rorvick
Sent: Sunday, 9 December 2012 4:54 PM
To: Matthew Ciancio
Cc: git@xxxxxxxxxxxxxxx
Subject: Re: Feature Request - Hide ignored files before checkout

On Sat, Dec 8, 2012 at 6:06 PM, Matthew Ciancio
<matthew.ciancio16@xxxxxxxxx> wrote:
> Hi Chris,
>
> Yes, I don't think I have explained myself well enough.
>
> When I say "disappear" I do not mean "get deleted", I mean: go out of 
> view just like foo.txt does, as it is committed to branchB and not 
> merged into branchA.
>
> So I am saying that I think .gitignored files should behave partly 
> like committed and un-merged files, in the sense that they disappear 
> when checking out to a different branch.
> I don't want to commit these files (which would give me the behaviour 
> I want), because they are binary/OS specific and really do not belong 
> in the repository, BUT I need them to run/build certain committed files.
>
> To be concrete: I want ignore.txt to be ignored in branchB and hence 
> disappear (in the same way that foo.txt will), when checking out to
branchA.
> When I checkout back to branchB I want ignore.txt to reappear (in the 
> same way that foo.txt will).
>
> I understand why this behaviour is not happening (because my 
> .gitignore files are different between the branches), but I am saying 
> that I would like to have the option to keep my .gitignore'd files 
> local to the branch they are in.
>
> E.g. I currently have a branch with all these binary files that are 
> required to run an application on my OS, but when I checkout to 
> another branch I do not need or want those binary files anymore (at 
> least not until I checkout back into the branch I just came from).
>
> Please tell me if that still doesn't make sense.

Hi Matthew,

Cc'ing the list to benefit from the review of others.

Not wanting the files in the repository seems to be in conflict with the
desire to have them under its control (i.e., disappear/reappear
behavior.)  I understand not wanting to commit dependencies, but why do you
need them to disappear?  Why not just put them somewhere where they can be
used when needed and left alone when not?

If you do want this behavior, it seems like you should just commit the files
on the respective branch.  Maybe someone else will have a better idea,
though.

Chris

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]